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ABSTRACT 



This thesis gives a short, concise description of the U.S. 
Navy SNAP-II (Shipboard Non-Tactical Automated Data Processing 
Program) computer system, and through a post implementation 
review of six ships having the system installed, delineates 
concerns and problem areas with the SNAP-II system as perceived 
by the end-users. Major areas of concern that emerged were 
training, documentation, and the role of management in relation 
to the SNAP-II system, both internal and external to a U.S. 

Navy ship. An analysis of these issues is conducted and is 
the basis for recommendations on how to improve the SNAP-II 



program . 
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INTRODUCTION 



I . 

The SNAP- 1 1 (Shipboard Non- tactical Automatic Data 
Processing Program) program was initiated in response to a 
Chief of Naval Operations (CNO) objective to reduce the 
administrative burden on shipboard personnel, which would 
have a resultant improvement in fleet readiness and a 
positive effect on the morale and retention of personnel. 

As conceptualized, the system would provide automatic 
data processing equipment to small surface ships and submarines, 
reducing the manual burden on personnel in the administration 
of maintenance, supply, and pay and personnel matters. The 
system was designed for a life cycle of twenty years, with a 
key proviso in its charter being that additional personnel 
would not be required to operate or maintain the equipment. 

The program has been referred to. by various agencies as 
a "Real-time MIS" [Ref. l:p. 1], a system to "provide 
automated support for maintenance, supply, and pay and 
personnel functions" [Ref. 2: Enel. (3), p. 5], and "Automated 
Information System" [Ref. l:p. 1] and [Ref. 3:p. 1], all of 
which have different connotations of expected use. 

The current program calls for the installation of a total 
of 459 SNAP-II systems--!? at shore sites for training and 
support, and 442 on afloat units. As of 31 January 1986, 105 
systems have been installed afloat (55 Pacific fleet, 50 
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Atlantic fleet) and three at shore locations. No submarines 
have yet had the system installed, although the first 

installation has been scheduled to start in January 1986. 

With almost one-third of the systems installed in the 
fleet, a need was perceived to obtain user feedback to 
ascertain just how the ''fleet” was receiving the SNAP-II 
system and whether they were satisfied with the product. 
Subsidiary questions of whether the system was being utilized 
to its full capability by fleet units and adequately supported 
by the shore establishment were also of importance. 

The purpose of this thesis is to investigate end user 
satisfaction with the SNAP-II program, identify concerns and 
discuss emergent issues that may be of significance. This 
was accomplished through a post- implementation review of six 
ships, three of the Atlantic Fleet and three of the Pacific 
Fleet. As no submarines currently have the system installed, 
they were excluded. The reviews were conducted in January 
1986, using both open and closed format interview techniques. 
Personnel interviewed ranged from the Commanding Officers to 
senior enlisted personnel. The main thrust of the interviews 
was on a perceptive or subjective basis. Quantitative 
information was neither sought nor desired. 

Program and System descriptions are included in Chapters 
II and III, with the individual ship reviews and summaries 
contained in Chapters IV and V. Discussion of emergent 
issues follows, with conclusions and recommendations appearing 
in the final Chapter. 
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II. SNAP- 1 1 PROGRAM ORGANIZATION 



Program Organization is divided into two areas- -the 
internal organization of the ship (afloat) , and the Navy wide 
organization (ashore) that manages implementation, any changes 
to program direction, and provides assistance to correct 
material casualties affecting the SNAP-II software and 
hardware . 

A. SHIP'S INTERNAL ORGANIZATION 

With minor variances, the internal administrative 
organization of a typical Navy ship is shown in Figure (1) . 
Variations will exist between types of ships. A department 
is composed of several divisions, and each division is 
composed of of one or more work centers, which are the basic 
units for maintenance administration and personnel 
assignments . 

A department is headed by an experienced officer, with 
the divisions headed by junior officers. The work centers 
are headed by senior enlisted personnel. 

Superimposed on this organization is the SNAP-II 
Organization, Figure 2, which utilized the same personnel 
from the administrative organization in a secondary, or 
collateral duty basis to administer, operate and maintain the 
system. 
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NOTE: EACH DIVISION IS COMPRISED OF ONE OR MORE WORK CENTERS 






Figure 2. Shipboard SNAP Organization 
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The guidelines on who performs what SNAP- 1 1 tasks are 
contained in formal instructions issued by the Type Commanders. 
(The role of the Type Commander is delineated in Figure (3) . 

Of note is that the Type Commander has issued instructions 
concerning only the management ^ the SNAP- II system. 

Guidance as to how to manage with the system has not been 
issued at any level -- shipboard managers are left to their 
own initiative as to how to integrate the system within their 
management structure and style. Specific SNAP jobs and their 
responsibilities are covered in Chapter III. 

B. SNAP- 1 1 PROGRAM ORGANIZATION 

The SNAP- II program organization extends from the Office 
of the Chief of Naval Operations down to the individual ship; 
its purpose is threefold: 

- install and implement the program 

- repair any casualties to hardware or software 

- provide guidance and policy relevant to program changes 
and direction 

Figure (4) delineates the organizational relationships, but 
does not attempt to show the funding flow for the program. 
Several terms must be defined to understand the program: 

- Program Sponsor- - that office charged with overall policy 
guidance concerning the SNAP program 

- Program Manager- -coordinates all aspects of the SNAP- 1 1 
program 

- Functional Sponsor- -for each of the functional areas, 
certifies individual requirements to program manager 
and functional manager 

- Functional Manager- - executes the guidance of the 
Functional Sponsor by generating requirement specifications 
for software that must be developed. 
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Figure 3. Fleet Administrative Organization 
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Figure 4. SNAP II Program Management 





To execute SNAP-II installation and implementation, two 
agencies are directly involved; Naval Sea Systems Command 
(NAVSEA) and Navy Management Systems Support Office (NAVMASSO) . 
(The Type Commander is involved only from the aspect of 
scheduling) . NAVSEA, through NAVSEA Support Centers 
(NAVSEACEN ' s ) on the East and West coasts, supervises the 
installation of system hardware, which is done by the con- 
tractor, Systems Management American (SMA) Corporation. 

Software installation is accomplished by NAVMASSO, who has 
also assumed the responsibilities for coordinating the 
initial implementation on ships. 

Problems that develop after implementation are also 
handled by these two agencies - -hardware problems by NAVSEA, 
software problems by NAVMASSO. Problems can be reported 
through the formal CASREP method, or handled by initiating 
"Trouble Reports" to NAVMASSO for software problems, or 
"Direct Fleet Support" requests to the Type Commander for 
hardware problems, who will then coordinate action with 
NAVSEACEN’s [Ref. 4:p. 1] and [Ref. 5:p. 1]. 

User feedback for improvements or additions to the SNAP- 
II system is handled via a formal mechanism called "change 
proposals". They are forwarded by the ship to the Type 
Commander [Ref. 4:Encl. (3)] and [Ref. 5:Encl. (2)], who in 
turn will assess them and forward them to the Fleet Commander- 
in- Chief (The Type Commander may forward the change proposal 
to NAVMASSO for a cost-benefit analysis if that has not been 



17 



done.}- If fhs proposal has sufficient merit, it will be 
sent to the Program Coordinator (OP-945), who will pass it 
to the appropriate Functional Sponsor. The Functional 
Sponsor will approve/disapprove the proposal, and task the 
specific Functional Manager to develop specifications for the 
change if the request is approved. 

NAVMASSO incorporates the changes as directed by the 
Functional Managers, and the change is distributed to the 
fleet via updates to existing software or by completely new 
versions of the software. 

Issues of sufficient importance that cannot be resolved 
at the higher levels due to funding constraints or policy 
implications are referred to the Fleet Non-tactical ADP 
Policy Council. [Ref. 6:p. 4] 
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III. SNAP- II SYSTEM DESCRIPTION 



A brief description of the SNAP-II system elements is 
necessary to understand the essence of the system and the 
environment within which the system operates. These elements 
are : 

- Installation/ implementation 

- Hardware 

- Software 

- Personnel 

- Training 

A. INSTALLATION/IMPLEMENTATION 
1 . Principal Agencies 

There are three principal agencies that deal with an 
individual ship to install and implement the SNAP-II System: 

- Type Commander 

- NAVSEA 

- NAVMASSO 

The Type Commander is responsible for coordinating 
the ship's schedule for installation, obtaining training for 
the ship's Hardware Maintainers, and monitoring the progress 
of installation. [Ref. 7:p. 5] 

The respective NAVSEA Support Centers (Atlantic and 
Pacific) supervise the contractor's installation of hardware, 
coordinating their activities with NAVMASSO and participating 
in hardware certification [Ref. 8:p. 10-1]. Although not 
directly involved in hardware installation, NAVMASSO 
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coordinates the entire evolution and monitors progress 
through a "Milestone Tracking System" [Ref. 9:p. A-2]. 

2 . Software and Training 

Software and initial user training are the responsibility 
of NAVMASSO. Once the hardware is installed and certified as 
operational, the software installation and the loading of the 
data bases is done by NAVMASSO. 

Once software has been installed, NAVMASSO conducts 
training on board the ship for a period of two weeks. 

3 . Hardware 

The hardware installation can take three to seven 
weeks, depending on the class of ship (Table 1). Table II 
was compiled from various sources previously cited and 
delineates a "typical" installation schedule for a ship. 

Prior to commencing the installation, site surveys and 
preparations will be conducted by the contractor under NAV- 
SEACEN supervision. The contractor is responsible for 
providing all equipment and material incident to hardware 
installation [Ref. 7:p. 3]. 

4 . Data 

Software installation is preceded by the construction 
of various SNAP-II data bases. The ship itself is the source 
of the following items of data [Ref. 9:pp. 11-17]: 

- ship organizational information 

- ship personnel data 

- stock record card (NAVSUP 1114) data 

- material outstanding requisition file 

- COSAL 

- financial data 
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TABLE I 



HARDWARE INSTALLATION LENGTH 
Ship Class Installation Period 



FFG 


3 


WEEKS 


DD/FF/LST 


4 


WEEKS 


DDG/AE/AO 


5 


WEEKS 


AOR/CG/LPD 


6 


WEEKS 


CGN/BB 


7 


WEEKS 
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TABLE II 



SHIPBOARD IMPLEMENTATION EVENTS 



ACTION DATE 


EVENT 


RESPONSIBILITY 


D-180 


IDENTIFY SCHEDULE 
IDENTIFY SHIP’S CURRENT ADP 
EQUIPMENT 


NAVMASSO/ TYCOM 
NAVMASSO 


D-60 TO 90 


PRE- IMPLEMENTATION BRIEF 
SITE SURVEY 

STOCK RECORD CARD SURVEY 
OBTAIN TRAINING QUOTAS 
DATA COLLECTION FORMS TO SHIP 


TYCOM 

NAVSEACEN 

TYCOM 

TYCOM/NAVMASSO 

NAVMASSO 


D-49/D- 21 


SITE PREPARATION/ INSTALLATION 
(DEPENDING ON SHIP CLASS) 


NAVSEA/CONTRACTOR 


D-30 


DELIVER DATA FORMS TO 
NAVMASSO 


SHIP 


D-23 


CSMP CUTOFF 


SHIP/TYCOM 


D-17 


STOCK RECORD BATTERY, 
OUTSTANDING REQUISITION FILES 
PICKUP (FOR CONVERSION) 


NAVMASSO/ SHIP 


D-14 


STOCK RECORD BATTERY/FILES 
RETURNED TO SHIP 


NAVMASSO 


D-1 


HARDWARE SYSTEM TEST, NAVY 
ACCEPTANCE 


NAVSEA/CONTRACTOR 


D-0 


SOFTWARE/ DATA BASE LOAD 


NAVMASSO 


D+1 


USER TRAINING ON BOARD 


NAVMASSO 


D + 30 


SUBMIT ADPPRS DATA TO TYCOM 
SUBMIT OPNAV 4790/CK'S 


SHIP 
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External sources that provide data that will be integrated 
into the ship's data bases are as follows: 

- SPCC//NAMMSO- -Weapon Systems File (WSF) 

- Type Commander- -CSMP 

- NMPC- -personnel data 

- NWS Concord- -MEASURE data 

The collection of all the above information is the 
responsibility of NAVMASSO, who will convert them to electronic 
media or supervise a contractor who will perform the work. 

It should be noted that any activities or transactions that 
affect the various ship's files/records that occur during the 
conversion period when NAVMASSO is constructing the various 
data bases must be saved by the ship and entered in the SNAP- 
II System after implementation. The specific responsibilities 
are outlined in the SNAP- II Implementation Planning Document, 
promulgated by NAVMASSO [Ref. 9:pp. 7-11]. 

B . HARDWARE 

1 . Configuration 

The description of the hardware is divided into three 

areas : 

- Central Processing Unit (CPU) and Memory Devices 

- Peripheral Input/Output Devices 

- Support Equipment 

The exact configuration for each ship class is shown in 
Table III, with the relationship of the equipment layout 
illustrated in Figure (5) [Ref. 8:pp. 2/1-2/9]. 

2 . CPU 

The Central Processing Unit is an off-the-shelf 
commercial product, the HARRIS H300 mini-computer. It is 



23 



TABLE III 



SNAP- 1 1 HARDWARE ALLOWANCE BY SHIP CLASS 



Large/ 

Hardware Manufacturer Trident 

CPU Harris H500 ^ 

Word Processing NEC Model 7710 4 

Printer 

Display Printer FACIT Model 4500 8 

Line Printer Printonics Model P-300 2 

Floppy Disk Drive SMS 2 

Terminals Beehive Inti Model 8586 17 

Card Readers ITL 1 

Paper Tape Reader Remex 1 



* Nine locations available for terminal hook-up 



Class 

Medium 

/SSBN 

1 

2 

2 

2 

2 



SSN 



1 

0 

1 

1 

1 



13 



1 0 
1 0 
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WORD PROCESSING 
PRINTERS 









c/^ 






>-< 
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w 




H 




Z 


in 


1— 1 


h-t 




Q 


P-. 




0) 

u 

cd 

"O 

5-1 

03 



5-1 

Q) 

:=) 



P-. 

c 

C/3 



LO 

03 
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TYPICAL SUPPLY ARRANGEMENT 




installed in a rack cabinet that also includes Hard Disk 
Memory Storage Units, perforated paper tape and magnetic tape 
input/output devices. Another input/output device, the floppy- 
disk drive, is co-located in the same compartment as the CPU 
and rack cabinet. 

3 . Peripheral Devices 

The peripheral input/output devices include the user 
terminals (KVDT- - Keyboard Video Display Terminals), various 
types of printers, and a paper card reader, which is usually 
installed in the Supply Department. 

The KVDT's are the devices through which the users 
interact, or use, the SNAP-11 system. It is a Cathode Ray 
Tube (CRT) with a keyboard attached. 

There are three kinds of printers associated with the 
system. A line printer is used in high volume printing jobs 
using 16 inch wide computer paper. A word processing printer 
produces letter- qual ity correspondence on standard size paper 
and a display printer provides a copy of what the user is 
actually seeing on his KVDT screen. 

4 . Support Equipment 

The support equipment installed will be discussed 
only briefly, as the user is not directly concerned with them. 
These include electrical compensators for protecting system 
components from electrical outages or surges, and the com- 
munications subsystem, which allows for communication from 
the CPU to the various memory devices and peripheral equipments, 
such as printers and KVDT's. 
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C. SOFTWARE 



The SNAP- 1 1 system was designed to "reduce the burden on 
shipboard personnel and freeing personnel resources for use 
in other areas." [Ref. l:p. 1] The software, written in 
COBOL, embodies this goal. Software is the collection of 
programs that are used to perform tasks (e. g., controlling 
hardware, maintaining the CSMP, inventory management). 

1 . Software Categories 

The SNAP- 1 1 software is divided into two general 
categories: system software and application software, 

a. System Software 

System software consists of operating system 
programs and utilities. The operating system controls the 
hardware, and the utility programs are used to perform 
general functions in support of all software. The system 
software is provided by Harris as part of the hardware 
package. The following is a brief description of the 
software provided: 

(1) Vulcan Operating System (VOS) . An operating 
system is a group of programs that "govern the control of 
equipment resources such as processors (CPU) , main storage 
memory, secondary memory (disk, tape), Input/Output devices, 
and files." [Ref. 9:p. 1] In simple terms, the operating 
system makes the hardware work together to achieve the 
intended results of the application software. 
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(2) Utilities . The following utilities are 



provided : 



- MUSE- -a word processing program 

- BASIC- -a programming language 

- Sort/merge -- a file processing program 

b. Application Software 

The application software is designed, developed, 
and maintained by NAVMASSO, the Central Design Activity (CDA) . 
The following are descriptions of the subsystems that comprise 
the application software: 

(1) System Management Subsystem (SMS) . The SMS 
"performs system management and service tasks in support of 
the other functional subsystems." [Ref. 8:p. 2-19] SMS 
controls file access, provides on-line user manuals, controls 
report queuing, and provides user-to-user message processing. 
"The SMS also ensures the protection of system data integrity 
by providing backup, recovery, and transaction logging 
functions." [Ref. 8:pp. 2-19] Figure (6) depicts the SMS 
subsystem. 

(2) Maintenance Data Subsystem (SMS) . MDS will 
consist of the Organizational Maintenance Management System 
(OMMS) and the Planned Maintenance System (PMS) when 
released . 

The Organizational Maintenance Management System (OMMS) 
provides organizational maintenance capability. This 
system includes 3-M functions related to the Current 
Ship's Maintenance Project Master (CMPM) data base. This 
data base consists of Maintenance Data System (MDS) 
actions. Configuration Change (CK) actions. Ship's Force 
Work List (SFWL) action, TECDOC maintenance, and MEASURE. 
[Ref. ll:p. 3] 
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REPORT QUEUE 
MANAGEMENT FUNCTIONS 




SYSTEM MANAGEMENT SUBSYSTEM 

FIGURE 6 
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Figure (7) depicts the MDS subsystem. 

(3) Supply and Financial Management (SFM) . 

The Supply and Financial Management Subsystem (SFM) pro- 
vides support for those functions specifically related 
to supply and financial management, including parts 
ordering and monitoring, inventory management and financial 
budgeting and reporting. [Ref. ll;p. 5] 

Figure (8) depicts the SFM subsystem. 

(4) Administrative Data Management (ADM) . This 
subsystem provides support for administrative functions 
relating to personnel management. Figure (9) depicts the 
ADM subsystem. This subsystem's programs include the 
following ; 

- control of berthing assets 

- assignments to lifeboats 

- personnel assignments 

- watch bill preparation and coordination 

- personnel school data 

- security information on personnel 

- department/divis ion records 

- immunization status of personnel 

- medical examination status 

- medical and dental appointment control 

- advancement and career counselor data 

- prospective gains/losses 

(5) Mobile Logistics Support Force (MLS) . 

The MLS automated data processing system interfaces and 
supports the replenishment functions aboard AE, AO, AOE, 
and AOR class ships. It automates all Special Accounting 
Class (SAC) 224 material handling processes, including 
producing necessary reports. Additionally, it interfaces 
with the Underway Replenishment (UNREP) system on board 
AFS's and produces fleet commander statistical reports. 

[Ref . 1 : p . 16] 

2 . Fleet Introduction of Software 

NAVMASSO Introduces software to the fleet by the 
following methods: 
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ORGANIZATIONAL MAINTENANCE MANAGEMENT SUBSYSTEM 

FIGURE 7 
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SUPPLY AND FINANCIAL MANAGEMENT SUBSYSTEM 
FIGURE 8 
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BERTHING 



DEPARTMENT/ 

DIVISION 



HEALTH 

AND 

MORALE 



WATCH BILL 



ADHINISTRATIVE DATA MAHA6EMENT SUBSYSTEM 



FIGURE 9 
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- implementation on ships without SNAP- 1 1 

- back fit of new releases on ship's with SNAP- II 

- interim changes to existing programs 

Implementation and back fit of releases are accomplished by 
NAVMASSO personnel. NAVMASSO uses releases to introduce new 
subsystems or major changes to existing programs. Interim 
changes (updates) to programs are forwarded to the ships by 
mail and the ship's System Coordinator loads the update into 
the SNAP- 1 1 system. A summary of software releases is 
provided for historical perspective. 

a. Initial release 

(1) Maintenance Data Subsystem (MDS) . The initial 
release provided the user with the basic programs to process 
maintenance actions into the Ship's Force Work List (SFWL) 

and the ability to enter data used to generate supply material 
requirements for both internal and off-ship processing. 

(2) Supply Financial Management (SFM) . The 
initial release provided the user with limited automated 
support for parts ordering and monitoring, inventory management, 
and financial budgeting and reporting. 

(3) System Management Subsystem (SMS) . The 
initial release provided control over all subsystems and user 
ability to review the on-line User Manual's. 

b. Release 2 

(1) MDS . This release added programs for Current 
Ship's Maintenance Project (CSMP) , completing maintenance 
actions (CK generation), test equipment calibration function 
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(MEASURE), Ship's Equipment File (SEF) and an expanded 
Technical Document (TECDOC) Module. 

(2) SFM . This release added programs for on-line 
requisition status processing, requisition history processing. 
Requisition Status File, Requirements Report and enhancements 
to reports. 

(3) Administrative Data Management (ADM) . This 
subsystem provided the data base and programs for manpower 
management, visitor control, and query language for report 
creation and generation. 

(4) SMS . This release added programs for update 
processing (adding interim changes), system access, backup 
procedures, system recovery procedures, output to paper tape 
or magnetic tape, peripheral equipment management and 
additional security enhancements. 

c. Release 3 

Release 3 of the software experienced extremely 
slow response times and "due to the amount of effort required 
to correct these problems" [Ref. l:p. 4] the release was only 
installed at two cities. 

d. Release 4 

Release 4 incorporated several vendor updates to 
improve system response time. These updates provided for 
more efficient data storage and retrieval, freeing up of 
disk space, and the ability to link one program to another. 
Release 4 included the following updates to subsystems: 
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(1) MDS . This release added a program for bulk 

CSMP input . 

(2) SFiM . This release provided enhancements to 



financial program reports, requisition processing, and 
inventory reports. 

(3) ADM, SMS, MLS . This release provided 
enhancements to provide greater accessibility and capability 
to existing programs. (Mobile Logistics Support (MLS) 
program was added as part of an update to Release 2) . 

e. Approved Software Changes to SNAP- 1 1 

The following are the planned modifications to 
existing programs and additional programs that have been 
approved for implementation; 

(1) Release 5 

Release 5 is projected to be introduced in 
FY 1986. The programmed modifications are as follows: 

- SFM Transaction Ledger 

- SFM Inventory/Financial Audit Trail 

- SFM Inventory Level Setting 

- MDS Automated COSAL Maintenance 

- MDS Multiple COSAL Support 

(2) Release 6 

- SFM DLR Carcass Tracking System 

- LOGMARS receipt processing 

- Submarine supply/f inancial 

- Effectiveness Report 

f. Future Planned Applications 

- Training 

- Planned Maintenance System (PMS) 

- Aviation Maintenance Subsystem (AMS) 

- Light Airborne Multipurpose System (LAMPS) 
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- Logistics Application of Automated Marking and 

Reading Symbols (LOGMARS) 

- Food Services 

- Retail operations 

- Medical and dental 

- Source Data System Afloat (SDSA) - -Disbursing and 

Personnel 

- Ship's Force Overhaul Management System (SFOMS) 

- Technical Library 



D. PERSONNEL 

1 . Concept of Manning 

The design and concept of the SNAP-II System is 
predicated on the requirement that no additional personnel be 
required to manage, operate or maintain the system [Ref. 2: 
p. 1] , and that these duties be performed by existing ship- 
board personnel on a collateral duty basis. 

Both Atlantic and Pacific fleet surface Type 
Commanders have issued instructions [Ref. ll:pp. 3-6], [Ref. 
12:Encl. (1) pp. 2-4] delineating specific system responsi- 
bilities. Both closely follow the Management Guide issued 
by NAVMASSO [Ref. 1 : pp . 20-24]. 

The following collateral duty billets are identified: 

- System Coordinator 

- Assistant System Coordinator 

- Functional Area Supervisors 

- Hardware Maintainers 

2 . Specific System Requirements/Assignments 
a. System Coordinator 

An officer or chief petty officer will be 
responsible for: 

- implementation, operation, and maintenance of the system 

- primary point of contact for the ship 
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- coordinate, monitor, and schedule system usage by 

Functional Area Supervisors 

- perform backup, recovery and update procedures 

- system security and integrity of data bases. 

b. Functional Area Supervisors (FAS) 

Each subsystem implemented on board a ship will 
have a Functional Area Supervisor. The FAS will be an 
officer or senior petty officer whose skills and knowledge 
in that area qualify them for such designation. His 
responsibilities include: 

- ensuring integrity of data base 

- ensuring security procedures are followed 

- assigning access to personnel 

- conducting training for all users 

- being responsible for implementing all facets of his 

functional area 

c. Hardware Maintainers 

The Hardware Maintainers are rated Electronics or 
Data Systems Technicians, with two specified per installation. 
The Hardware Maintainers are responsible to the System 
Coordinator for the preventive and corrective maintenance on 
the SNAP-II system. 

d. Users 

The Managment Guide and Type Commander instructions 
specify two types of users: journeyman and basic. Basic 

users will normally only perform data entry and retrieval 
operations for a specific task within one functional area. 
Journeymen users have more capabilities in the system, and 
have the capability to perform multiple tasks within a 

functional area or can have access to more than one functional 
area, as designated by the Commanding Officer. 
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E. TRAINING 



1 . Concept 

SNAP- II training has been conceptualized as a two- 
phased approach- - initial and follow on training, with each 
of these sub- categorized as to whether it is conducted on 
board or off-ship [Ref. 13:pp. 146-150]. Table IV illustrates 
this concept. 

The initial training is conducted during the initial 
implementation of the system on a ship. This is performed 
by NAVMASSO (Systems Coordinators and on board user training) 
and by SMA (Maintainers) . NAVMASSO will conduct all initial 
implementation training, whereas maintainers training will 
transition to FTC Norfolk and FTC San Diego at some point in 
the future. 

Follow on training is to be the responsibility of the 
Navy training establishment, with 10 (possibly 12) commands 
identified to conduct this training [Ref. 13:p. 126]. Pro- 
jected Navy-wide training and education programs will involve 
the assignment of NEC's to various system personnel, 
development of PQS and on board training materials for the 
various functional areas and self-study workbooks [Ref. 13: 
pp . 160-164] . 

Follow on training on board ships is a ship 
responsibility, with training materials to be provided. 
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TABLE IV 



SNAP- 1 1 TRAINING 



ON SHIP 



OFF SHIP 



1 

1 

Initial ' Implementation training 

; by NAVMASSO 
1 
1 
1 
1 
1 
1 
1 
1 
1 
1 
1 
1 


Maintainors (SMA) 

Ship System Coord- 
inators (NAVMASSO 

PCO/PXO (NAVMASSO) 


1 

Follow on Not specified (ship's 


1 

Maintainor (May 86 


1 responsibility) 


RFT) PCS Pipeline 


1 

1 


Ship System Coord- 


1 

1 


inator (TAD/PCS) 


1 

1 

1 


PCO/PXO (FTC's) 


1 

1 


3-M Systems Coord- 


1 

1 

1 


inator 


1 

1 

1 


Leading Storekeeper 


1 

1 

1 


SNAP Admin Mgt Super 


1 

1 

1 


SWOSCOL for CO/XO/ 


1 

1 

1 

1 

1 

I 


DH/DO 
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2 . Training 



In the initial and follow on training phases, specific 
formal training courses are provided for the following 
personnel : 

- Systems Coordinator 

- Hardware Maintainer 

* - 3-M Coordinator 

* - leading Storekeeper Afloat 

* - SNAP- II Administrative Management Supervisor 

* not implemented as of 31 January 1986 

Surface Warfare Officers training is to be included as an 
adjunct to the PCO, PXO, Department Head and Basic courses 
conducted by SWOS, although this has not formalized and in 
place as of January 1986. There is no mention of Submarine 
Officer training. Training for Supply Officers is being 
conducted at NSCS, Athens, Ga. 

Training materials for on board initial and follow 
on training are prescribed in the Navy Training Plan as well. 
They include training for Journeyman/Basic User and Functional 
Area Supervisors for initial training, and the following for 
follow on training (for each subsystem) [Ref. 13:pp. 163-164]: 

- Functional Area Supervisor Trainee Guides 

- Journeyman/Basic User Instruction Guides and Trainee 

Guides 

- Self-Study Workbooks 
3 . Transition 

The transition process has experienced some delays. 
Approval of the Navy Training Plan was dated 1 April 1985, 
almost two years after the first SNAP-II installation on a 
ship . 
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Currently, NAVMASSO is the primary agent for 



conducting SNAP- 1 1 training. In accordance with the Navy 
Training Plan for SNAP-II [Ref. 13], full transition to 
follow on training was scheduled for Calendar Year 1986. 

Some training establishments already have instituted some 
SNAP-II training (NSCS, Athens; SWOS) . The planned "ready 
for training" dates are contained in the Navy Training Plan 
[Ref. 13:p. 126]. Various sources have indicated that these 
dates may not be realistic and may slip. 
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IV. CASE STUDIES 



In order to ascertain the end users views and concerns 
with the SNAP-II system, six ships were visited and inter- 
views conducted with key personnel. The interviews were 
both structured and unstructured, depending on the response 
of the individual interviewed. 

A "topdown" concept of interviewing was selected so as to 

obtain a valid organizational picture. Data entry users were 

excluded from the interview process because of time and 

personnel limitations and the narrow view data entry personnel 

would have of the system. The assumption was that problems 

or concerns at the lowest level would be evident at the next 
•» 

higher level or levels because of the highly structured 
organizational hierarchy inherent on a U.S. Navy ship. 

Three levels of personnel were interviewed: the command 

level personnel (Commanding Officer and Executive Officer) , 
Department Heads, and the personnel responsible for actual 
system operation and maintenance (System Coordinator, 
Functional Area Supervisors, and Hardware Maintainers) . 

The results of the various interviews are presented in 
the following six case studies, or reviews. The comments and 
observations of the ships personnel are presented without 
comment from the authors. Summaries and specific commentary 
are presented in the Chapters following the case reviews. 
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A, CASE 1 



1 . Introduction 

The SNAP-II system was installed during January of 
1984 on this Guided Missile Cruiser homeported on the West 
Coast. Full transition to SNAP-II occurred in February, just 
prior to and during the initial at sea period of a major 
forward deployment to the Western Pacific. Prescribed user 
training for shipboard personnel was conducted underway while 
enroute to the first port visit of the deployment. 

There was very positive command support during the 
installation and implementation of the system. Of the data 
bases (WSF, personnel, CSMP) that were loaded at implementation, 
various pieces of information were missing, causing some 
degree of user mistrust at the outset. Subsequently, the 
ship has experienced a minimum of problems with the system, 
due to strong user and management involvement and excellent 
support from NAVMASSO and NAVSEACENPAC . 

Figures (1) and (2) in Chapter II delineate the 
integration of the SNAP-II system operational and maintenance 
responsibilities within the ships internal organization. A 
Senior Chief Petty Officer (SKCS) from the Supply Department 
is assigned as the System Coordinator, with the ship's 3-M 
Coordinator, a Chief Petty Officer (EMC), as the assistant 
coordinator. The assistant is also assigned as the Functional 
Area Supervisor for the MDS subsystem. The same SKCS is also 
assigned as the Functional Area Supervisor for the SFM 



44 



subsystem, with the Supply Officer strongly involved. A first 
Class Petty Officer (PNl) is the FAS for the ADM subsystem. 

Hardware maintenance is performed by Data System 
Technicians (DS rating) , although the administration of the 
maintenance activities is under the cognizance of the 
Electronic Technician workcenter. This evolved because the 
ship’s Electronic Technicians (ET rating) originally performed 
the maintenance, but for various uncited reasons, this 
responsibility was shifted to the Data System Technicians. 

The hardware installed is in accordance with the specifications 
for a ship of her class and size. 

Training for users is centrally managed and scheduled 
through the weekly meeting of the ship's Planning Board for 
Training. The actual training sessions are conducted by the 
individual Functional Area Supervisors. 

The ship is currently using version 4.00.06 of the 
SNAP- II software, with version 4.00.07 on board and awaiting 
installation. SNAP-II is considered an integral part of the 
internal adminstration of this ship and is strongly supported 
and used at all levels of the chain-of -command . It's use is 
so widespread that system backups are planned carefully and 
receive high level attention so as not to interfere with the 
users . 

2 . Command Perception 

The Commanding Officer had been in command for six 

months at the time of the interview. He had not been aboard 
during installation and implementation of the system. 



45 



The Captain spoke highly of the SNAP- 1 1 system and 

indicated that it was used extensively by all levels in his 

command. Summarizing his feelings, he stated: 

Quick and dirty, I love it. I'm a supporter of SNAP-II 
and it's used extensively on board the ship for other 
things . . . sometimes, we get carried away. 

The Captain attributed the successful implementation 
of the system to the talent and dedication of the various 
users and managers, feeling that a ship without the resources 
he had probably would not fare as well. Because of the 
talented people on board, he felt that they were able to do a 
great deal of learning and experimenting for themselves, 
which had led to less dependence on formalized training to 
successfully integrate the system into the ship's routine. 

The right people with the right attitude was the key to 
success . 

The Captain expressed his views about the impact of 
the system on his command from several perspectives. One was 
the proliferation of information available, and the other was 
the positive effect on the management of his ship. 

a. Management 

The accuracy and timeliness of reports available 
from the SNAP-II system was the key ingredient that the 
Captain felt had contributed in a positive manner to the 
internal management of his command. He was most enthusiastic 
about the MDS subsystem and its ability to maintain and 
provide accurate information about the ship's maintenance 
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activities through the CSMP (Current Ships Maintenance 
Project) reports. The savings in man-hours in data-entry and 
the timeliness of obtaining reports in comparison with the 
former manual method and dependence on external ADP activities 
was significant: 

The last time I was at sea, you never got it right (the 
CSMP) , because by the time it came back from the Type 
Commander, a month, 6 weeks had elapsed and you were 
always behind- -you could never pick up the CSMP and say, 

' this is IT' . 

The Captain felt that the ability of his 
Department Heads to effectively manage was enhanced because 
they were able to obtain and rely on information that had not 
previously been utilized to its full extent. He did not 
indicate that the style or manner of management had changed, 
only that previous methods and procedures had been strengthened 
through the use of SNAP- generated information. As an example, 
he cited the ease with which the ship had been able to under- 
go an INSURV inspection (INSURV is the acronym for the Navy 
Board Of Inspection and Survey, an independent activity that 
reports to the CNO on the material condition of ships) . The 
ease and accuracy with which material discrepancies had been 
documented and acted on was a direct result of being able to 
have an accurate CSMP instantaneously available for management 
to work with and plan for remedial action. 

Although the Captain had a great deal of 
enthusiasm for the system, he did not have a terminal in his 
cabin, nor did he want one. He felt that his having one would 
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border on "micro-managing” his subordinates. If he wanted 
information about anything, he would do as he had done in the 
past--summon the person responsible and ask for the information, 
b. Proliferation of Information 
. . . sometimes we get carried away ... 

In some cases, the Captain felt that he had 

available too much information; more than he could use. He 

cited as an example the ship's 8 o'clock reports (reports 

forwarded to the Commanding Officer by the individual 

departments about their material condition at 8 PM each day) : 

. . . in some cases they're giving me more information than 

I need, but after a while you learn where to look. Some 8 
o'clock reports from a department will be four pages long, 
because they'll have everything there, whereas before we 
used to say, 'what got broke, what broke today, and what 
got fixed today.' So, we're adding a summary sheet on 
top of the whole pile. 

5 . Middle Level Management and SNAP- I I 

The term "middle level managers' applies to those 
officers in charge of the various departments on the ship. 

Those officers interviewed included the Operations Officer, 
the Combat Systems Officer, the Supply Officer, and an officer 
representing the Engineering Officer. The Engineering Officer 
was not interviewed because he had been on board a relatively 
short period of time, and the officer designated could provide 
a better insight with respect to that department. 

Of the Department Heads, only the Supply Officer had 
a background in computer systems, having a B.S. degree in 
Data Processing. None of them had any prior experience with 
nor any formal training on the system. 
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As a group, these officers mirrored the Commanding 
Officer's opinion that the SNAP- II system was a significant 
management tool, indicating that they themselves and the 
personnel in their departments used not only the specific 
reports the system provided, but were also adapting the word 
processing system and mail facilities to their personal needs 
to save time, communicate ,• and produce their own reports. 

The benefits derived from the SNAP- 1 1 system were not 
quantifiable in an objective manner, but subjectively these 
officers felt that the efficiency of their departments was 
enhanced. Personnel were spending less time preparing 
maintenance and supply documents, getting faster responses 
from the supply system, and in general were more accurate in 
what data they v\rere entering to the system. Because of the 
increased accuracy, faster response and the reports available, 
managers at all levels were able to manage more effectively. 

Although these officers did not indicate that SNAP- II 
has changed their management style, one officer did note that 
since implementing the system, there has been a proliferation 
of formal ship's Notices. These Notices gave formal 
instruction for the conduct of specific ship's evolutions 
that had in the past been promulgated verbally or through the 
Plan of the Day, which is a daily schedule of the ship's 
routine and special events. 

As a group, these officers were uniformly pleased 
with the SNAP-II system, considering it a vast improvement 
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over the former manual methods. Their enthusiasm, however, 
did not blind them to problems with the system or improvements 
they felt should be incorporated. These concerns were in the 
following areas: 

- documentation 

- training 

- system Improvements 

a. Documentation 

System documentation was not helpful from the 
middle-managers point of view, in contrast with little 
objection or complaint being reported from the personnel who 
use the system for data entry. Asked whether they found the 
documentation easy to use and effective in acquainting them 
with the capabilities of the system, these officers responded 
negatively across the board. 

The main thrust of their complaints was that the 
documentation did not give them an adequate overview of the 
system and that it was not written in terms that they could 
readily understand. As a result of this, they reported that 
experience was the best teacher- - they had to use the system 
extensively in order to understand and be familiar with the 
documentation . 

b. Training 

Training system users is a well coordinated and 
executed evolution, with the only negative comments directed 
at the initial implementation training, which had been 
conducted underway enroute to a major deployment. 
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Recommendations for follow-on training was the 
main point that the Department Heads had, as there is presently 
none available on a formal basis, nor are training aids 
provided for shipboard use. The following suggestions were 
provided: 

- development of interactive training programs for users 

- development of various video-taped training programs 

- develop a shipboard training package 

- provide a waterfront training program similar to ones 

that exist for 3-M and Damage Control Petty Officers-- 
i.e., a short (five days or less) class scheduled and 
conducted locally 

c. System Improvements 

The Department Heads expressed ideas on how to 
improve the system and add new applications. For reasons 
that were not clear (perhaps not being familiar with the 
administration of the SNAP-II system), few of these have been 
formally requested through official channels via the "Change 
Proposal" mechanism provided for in the Type Commanders 
directive concerning the administration of the 'SNAP-II system. 
Most of the suggestions related to producing formatted reports, 
such as CASREPS (reports of equipment casualties) and enlisted 
evaluations, and as such will not be listed here. 

4 . System Operation and Management 

The following personnel are assigned SNAP-II system 
responsibilities : 

- System Coordinator- - SKCS (also the SFM FAS) 

- Assistant System Coordinator- -EMC (Also the MDS FAS) 

- ADM FAS--PN1 
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The choice of these individuals was fortunate- -with the 
exception of the MDS FAS, there was a high degree of computer 
system knowledge. The SKCS had an Associate Degree in the 
computing field, and the PNl had nine years experience working 
with computer system's in various shore duty assignments. None 
of these individuals had any experience with the SNAP-II 
system prior to their present tour of duty, 
a. Maintenance 

Hardware maintenance is performed by Data System 
Technicians (DS rating) , who felt that the training received 
was good, and that the technical documentation was more than 
adequate for them to perform their duties. 

One concern expressed by the maintainers (and 
supported by the System Coordinator) was the location of the 
SNAP-II computer itself. It is located directly over the 
after engine room and cooling could be a problem. Any dis- 
ruption of air-conditioning service to the space would mean 

a rapid rise in the ambient temperature, and it was recommended 

\ 

that an interlock between the computer and the air-conditioning 
be installed to prevent heating problems and system crashes. 

In this manner, "graceful" system degradation could occur, 
giving users ample time to save their files. 

Maintaining the system on a collateral duty basis 
did not present a particular problem in terms of coordination 
or xvorkload, just in the question of when the maintenance is 
performed. Because of the heavy use of the system, any 
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preventive maintenance has to be done after working hours, 
and often late at night. 

b. System Coordinator and SFM FAS 

The system coordinator felt that the formal 
training he received from NAVMASSO was "too fast”, indicating 
that he had barely assimilated system terminology before 
instruction had moved into the operational aspects of the 
system. Despite this initial drawback, he had not experienced 
problems in actually running and managing the system. He felt 
he had a good understanding of the system and his responsi- 
bilities, and he interacted well with all levels of system 
users and managers within the ship. 

The Senior Chief had not experienced any problems 
with the system documentation, and felt that the SMS subsystem 
was performing adequately. 

In the SFM subsystem, his only recommendation for 
change was the inclusion of a Storekeeper (SK) training manual. 
While he considered the documentation adequate for use of data 
entry personnel, he wanted his people to understand what was 
happening "inside” the program, and as such needed a good 
training document to guide him. 

Hardware maintenance was considered more than 
adequate, with no problems reported in scheduling or 
executing maintenance. As far as the hardware was concerned, 
the only major issue was the lack of enough user terminals. 
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The Senior Chief did have ideas on system 



improvements in the SFM area, although he did not indicate 
that these ideas had been formally submitted as "change 
proposals" up the chain-of -command . Most of his recommendations 
concerned specific details of entering and retrieving individual 
items of data and formatting, and will not be listed here. 

Overall, The Senior Chief was pleased with the 
system and had nothing but praise or constructive comments 
to make. 

c. Assistant System Coordinator and MDS FAS 

Although not having a computer background as the 
other key personnel in SNAP- I I management, the MDS FAS was 
comfortable in his job and had a good working knowledge of 
the system and his particular subsystem. He had the most to 
say about the specific functions of the system during the 
course of the interviews, perhaps due to his excellent know- 
ledge of the 3-M system and his desire to make the subsystem 
mirror his capability and knowledge about procedures and 
requirements in the 3-M system. 

In the area of system training, the MDS FAS 
recommended that formal training be set up for the functional 
area supervisors. In this manner, they could become the 
system "experts" prior to assuming the job, instead of having 
to learn as they went along, and not have to rely on what 
their predecessors in the job had passed on (or neglected to 
pass on) in the course of the relieving process. 



54 



The Chief was generally pleased with the perfomance 
of all aspects of the MDS subsystem, and indicated that the 
success of the system was partially due to the strong 3-M 
system that was in place on the ship prior to the implemen- 
tation of SNAP-II. To this end, he noted that there is no 
guidance from the 3-M system (Documentation) on the subject 
of how to integrate the SNAP- II system to it, and that this 
had caused some minor problems in dealing with the shore 
maintenance establishment. 

Overall, the system documentation was felt to be 
adequate, with the on-line user "help” feature considered a 
major contributor to the accuracy achieved by the data entry 
personnel • 

System hardware was considered excellent, with 
the floppy disks being the only problem area identified. They 
were considered unreliable to use because of problems in data 
transfer- - sometimes they did, sometimes they didn't- -and as 
such were not used. This problem had been identified to 
NAVMASSO, but no action had been taken to date. 

In summary, the Chief was satisfied with the 
system, although he had pointed our various instances of 
software "bugs". He felt that the system had been integrated 
successfully into the ship's routine and that it was being 
used to it's full extent, 
d . ADM FAS 

Despite a slow start in system use after 
implementation because of slow response times and problems 
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with the personnel data base, the ADM FAS rated the system as 
"good", and would like to see new additions to the program, 
such as the ability to generate enlisted evaluations. He 
reported that the "query" function of the subsystem was used 
extensively, and that the personnel that worked for him were 
using the system in a satisfactory manner. 

System documentation was not an issue, as the 
personnel using the ADM subsystem relied heavily on the on- 
line "help" feature to guide them in lieu of using any written 
documentation. The initial training of personnel was not an 
issue, nor was the subject of ongoing training. 

Training for the FAS himself was the major issue 
he raised, indicating a need for formal training before 
assuming the job. This would ensure a proper "turnover" when 
one person relieved another on the job, and insure a continuity 
of knowledge and adequate leadership and management. 

B. CASE 2 

1 . Introduction 

The SNAP- II system was installed in two phases on 
this Guided Missile Cruiser homeported on the West Coast. 
Normally, installation is scheduled for a single time frame, 
but in this instance it was split. This was due to the ship's 
desire to accelerate the process in anticipation of the 
upcoming operational schedule, which would have otherwise 
dictated the installation at a much later point in time. 
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With the concurrence o£ the Type Commander and the 
SNAP-II project manager, the initial hardware installation 
was performed in December of 1983 while the ship was nearing 
the completion of a regularly scheduled overhaul. Because of 
the accelerated installation and due to the unavailability 
of resources, only seven of 14 user terminals were installed. 

After completion of the first phase of installation, 
the ship’s manual records and documents were converted to 
electronic media, and version 2.0 of the application software 
was installed, with the system becoming operational in March 
of 1984. There were no major problems associated with the 
records conversion, although the conversion of COSAL records 
was incomplete, possibly due to the fact that the SOAP team 
validation of the existing COSAL had not been completed. Some 
initial training delays were experienced because of the lack 
of enough terminals and an insufficient amount of system 
documentation manuals (only two user manuals available vice 
one for each terminal) . 

The second phase of hardware installation was planned 
for a period of three weeks during August/September 1984, 
with an upgrade to version 4.0 of the software scheduled for 
the same period. This work fell behind schedule by several 
weeks, requiring the ship to put to sea on routine operations 
with a ''down” SNAP-II system. This disrupted the ship's 
ability to process standard maintenance and supply documents, 
of which they had now come to depend for entirely on the 
SNAP-II system. 
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At the time of the interview, the ship had the 
standard SNAP-II hardware configuration for a ship of her 
class and size, and had version 4.00.07 of the software 
installed. 

The attitude prevalent in the ship throughout the 
installation and implementation phase was positive; the 
command had been insistent on doing things right the first 
time. Since coming on line, the ship has experienced few 
problems with either the software or hardware. This system 
is considered to be very rugged and reliable, with satisfactory 
results being achieved. 

Figures (1) and (2) in Chapter II delineate the 
integration of the SNAP-II system operational and maintenance 
responsibilities within the ship's internal organization. 

The Assistant Supply Officer has been designated as the System 
Coordinator, with a Chief Petty Officer from the Supply 
Department (an SKC) assigned as his assistant. Maintenance 
on the hardware is performed by a Data Systems Technician (DS) , 
who is normally responsible for the operation and maintenance 
of the ships NTDS computers, and a Postal Clerk (PC). The 
Functional Area Supervisors are assigned in accordance with 
the directives of the Type Commander, Commander Naval Surface 
Forces, Pacific Fleet (COMNAVSURFPAC) [Ref. 12: Enel. (1), 
pp. 2-4] . 

SNAP-II appears to be successfully implemented in 
this ship, although not all facets of each subsystem are 
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being fully utilized. The system is well accepted throughout 
the ship, and has apparently not caused any radical changes 
in the way the ship manages or conducts its business. To 
date, there has been no effort to write individual software 
programs using the system's BASIC language programming 
capability, partly due to the perception that the system is 
already heavily loaded, and due to a lack of BASIC language 
documentation and training. 

There is no formal training program in place to teach 
system familiarization or utilization. Rather, the individual 
subsystem Functional Area Supervisors conduct training on an 
"as needed" basis and provide basic introductory sessions 
with newly-reported personnel who will be using that 
particular subsystem. 

2 . Command Perception 

The Commanding Officer had been in command for 18 
months at the time of the interview, and had not been on 
board during the initial SNAP-II hardware installation in the 
shipyard. His personal involvement and use of the SNAP-II 
system at the time was limited to using the MUSE word pro- 
cessing subsystem on the terminal in his cabin. Overall, he 
regarded the system, per se, as a very capable one for the 
functions it was performing, but felt that it could be 
improved in several respects. His basic expectation of the 
personnel using the system was not in the form of increased 
output, but of increased efficiency and accuracy. The end 
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result, he had found, was that people were not more efficient, 
but were merely doing business in another way. 

In contrast to the Commanding Officer, the Executive 
Officer had no comments to make about the SNAP-II system. 
Although he had a terminal in his stateroom, he did not make 
regular use of the system. 

The Captain had a limited exposure to computer systems 

through various academic courses, and stated: 

. . . I know what a computer ought to do for me, but I am 

not a computer 'buff. 

The major issues that were raised during the inter- 
view were not centered on specific aspects or attributes of 
the SNAP-II applications and systems software or hardware, 
but rather on broader aspects, such as documentation, security, 
and the effect of SNAP-II on the internal management of the 
ship . 

a. Security 

Regarding the issue of security of the system, 
the Captain was particularly apprehensive about the planned 
conversion of disbursing records to the Supply and Financial 
Subsystem of SNAP-II. His concern was that records would be 
accessible to unauthorized personnel, even though the system 
is protected by a system of individual access controls to the 
various subsystems through use of passwords. Concern was 
expressed about the manipulation of records, not the actual 
theft of cash. 
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In the Captain's opinion, any system with a 
central repository of records, such as the memory disks of 
the SNAP- II system, was susceptible to access despite any and 
all efforts to impose administrative controls. What was . 
needed, he thought, was a stand-alone computer where the 
physical control of the disk could be guaranteed- - i . e . , the 
disk could be locked up when not in use. He did not feel that 
the present security arrangements of the SNAP- 1 1 system were 
sufficient to guarantee that no unauthorized access could 
take place. 

b. Documentation 

The basic question raised by the Commanding 

Officer was, who was the system documentation aimed at. His 

perception was that it was written for people who understood 

computers to start with, and was not aimed at the manager's 

viewpoint. His personal experience on the system was that he 

was learning from other people, not from the documentation 

available. Describing the current documention as a "cookbook" 

for a user, he did not feel that it answered the basic 

questions as to what the system could do for him in his 

position as the Commanding Officer of the ship: 

How can the Commanding Officer of a ship with 'x' number 
of Department Heads use it? . . . There is a difference 

between button pushers and managers, and managers don't 
understand the system well enough to know what the system 
can do for them. 

From this perspective, the Captain felt that in 
addition to the "pushbutton" approach to documentation, a 
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"level -by- level” approach was required so that different 
levels of system users would be given different views and 
documentation on the system. By the "level -by- level" method, 
he meant that Department Heads, Division Officers, and 
command- level personnel (CO/XO) have different needs for 
different kinds of information, and that a manual describing 
the system from those reference points was needed. The "cook- 
book" approach only allowed him to look through documentation 
to find specific screens, but information on the whole issue 
of CSMP management or financial reporting for instance, was 
not available. 

Summarizing, he felt that to those people with 

a limited or non-existent knowledge of computers, SNAP-II 

failed miserably in its documentation; 

I MIGHT be able to get a hold of the information I need, 
but I DEFY anybody to go into the documentation and 
figure it out. 

c. SNAP-II and Management 

The SNAP-II system has caused the Commanding 
Officer to question the applications and usefulness of the 
system in two areas: whether it was a useful tool from a 

management oversight perspective, and whether or not the 
impact of the system on the efficiency of mid-level management 
(such as Department Heads and Division Officers) was a 
positive one or not. 

Explaining that a Commanding Officer had different 
requirements for information from the system than that of 
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others in the chain-of-command, the Captain felt that he 
could not obtain information of an analytical or aggregate 
nature from the SNAP- 1 1 system. What was needed, he felt, 
was number data about what was going on internally in his 
command--how many requisitions were backlogged; what is the 
spending trend of the ship? A particular department? A 
division? ; 

Many of the things I ask, the guy has got to go back to 
the manual thing to provide the answer. 

The Captain did not feel that the system was 

"management friendly", and that it could not provide the 

information he needed. While he would have liked many things 

from the system, he did find that at the lowest levels, that 

is, the level of people who had to use the system to carry 

out their everyday jobs, the system provided neatness and 

did lead to increased accuracy; 

If it was not intended for management oversight, its 
doing its job . . . from a managment viewpoint, I am 
not finding it useful. 

Regarding the net effect caused by the intro- 
duction of the SNAP-II system on the efficiency of management 
in his command, the Captain felt that there were basically 
two effects--one positive, one negative- -and that only time 
and experience with the system would yield a clearcut answer. 

The negative aspect was that officers were forced 
to sit down at a specific location (a computer terminal) to 
review and approve/disapprove supply requisitions or 
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maintenance action documents. The biggest problem was 
getting people to routinely sit down at a terminal and review 
the items awaiting their action. This was detrimental in 



several ways: 



- The officers are not provided with their own terminals, 
and must use terminals that are in use by the data-entry 
personnel, often "bumping” them. This delays either a 
user or an approver, and the work at hand is delayed. 

- Officers are engaged in a variety of tasks; management by 
walking around and inspecting is common. The end result 
is that an officer is "out and about" most of his working 
day (not to mention watch standing), and in the past, 
personnel could "walk through" important paperwork simply 
by approaching the officer anywhere on the ship, and he 
could approve/disapprove the item. This personal contact 
afforded the time and place for pointed questions about 
what was going on; with SNAP-II, this contact is lost 
and action might be delayed. 



On the positive side, the Captain 
that once an officer approved an item, it was 
entered into the system: maintenance actions 
and supply requisitions were in the queue for 



pointed out 
instantly 
were on the CSMP 
Supply Department 



action. This guaranteed that the CSMP was instantly updated 



and correct (a rarity in the past) , and that requisitions 



could be tracked and acted on with precision. The internal 



efficiencies of this were difficult to measure against the 



external inefficiencies cited previously. 

3 . Middle Level Management and SN.A.P-I1 

The term "middle level management" applies to those 
officers next in the chain-of -command under the Commanding 



and Executive Officers. In this specific case, those 
interviewed were the Operations Officer, the Weapons Officer, 
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and the acting Supply Officer. The Chief Engineer was not 
available. All are "Department Heads", in charge of a major 
administrative group within the ship. 

As a group, thes.e managers had little or no exposure 
to computers or computer systems prior to their current 
situation. The only formal training afforded them had either 
been conducted on board by NAVMASSO DETPAC during the 
implementation phase, or during introductory sessions on 
SNAP- II conducted at shore-side schools while they were 
enroute to the fleet. As discussed previously, the training 
during the implementation phase had been less than ideal 
because of the shortage of terminals. 

In contrast with the Commanding Officer, who viewed 
the SNAP-II system from a broader and more generalized 
perspective, this group of officers viewed the system with 
specific items in mind, and without a total system perspective. 
There was also a distinct difference in perspective and use 
of the system between line officers and the Supply Officer, 
perhaps due to the fact that the Supply Officer's "bread and 
butter" is tied directly to the SNAP-II system--he MUST use 
it to perform almost all aspects of his job, while this is 
not true of the line Department Heads. 

a. Line Management 

The line middle level managers (Department Heads) 
have not made extensive use of the SNAP-II system beyond 
those activities for which there is no alternative- -approving/ 
disapproving supply requisitions and maintenance action 
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documents. Word processing has been used, but not extensively 
The reasons cited for this were: 

- lack of formal training 

- lack of time for training after arrival on board 

- lack of terminal availability on board 

However, on the two subsystems that had to be 
used (MBS and SFM) , the Department Heads were pleased with 
the results and felt that their personnel were more accurate 
in their paperwork and tended to perform paperwork that in 
the past had not always been accomplished, such as deferred 
maintenance actions and changes to equipment configuration 
(CK's). They were not able to quantify increased productivity 
in their departments as a result of the SNAP-II implementation 
There was mixed response to the question of 
system documentation (user manual) adequacy, ranging from 
"good" to "poor". In general, they thought that their people 
had been adequately trained to use the system for the basic 
functions such as maintenance action reporting and generating 
requisitions . 

b. The Supply Department 

Overall, the opinion of the acting Supply Officer 
was that SNAP-II was a "great" management tool, providing for 
increased accuracy in financial reports and streamlining the 
processing of supply requisitions. Not all of the SFM 
functions were being utilized to one degree or another; for 
example, the SFOEDL and BOR routines had not been employed 
for several reasons: 
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- lack of understanding 

- time consuming to use 

- inability to change output (Budget OPTAR Report- - "BOR”) 
(BOR is a report that is cumulative in nature and only "seen" 
at the end of a reporting period--any changes or corrections 
require complete reconstruction.) 

Duplication was also occurring in several areas 
due to problems in program logic and lack of understanding 
and trust on the part of users and management. For example, 
the internal financial budget report was also being kept 
manually because requisitions in "queue" to the Supply 
Department, although not yet approved by an authorized person, 
were being subtracted from the ship's budget, causing an 
erroneous listing of the current budget balance. 

It was not felt that training on the system was 
a problem for the users- -the Supply Department conducted 
their own training for the users and considered them 
adequately knowledgeable in supply procedures to be able to 
effectively use the SNAP-II system. 

In summary, the acting Supply Officer considered 
that his department was coping very well with the SNAP-II 
system, although there were minor problems with it and the 
system was not being employed to the fullest extent possible. 
The apparent attitude was that in time, as people gain more 
experience with the system and as the system itself becomes 
more refined, greater use would be made of it. 
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System Operation and Maintenance 



4 . 

The Assistant Supply Officer is designated as the 
System Coordinator, with a Chief Petty Officer from the 
Supply Department as the Assistant System Coordinator. The 
Assistant Supply Officer is also the Supply and Financial 
Management subsystem Functional Area Supervisor (FAS) . The 
other Functional Area Supervisors are as follows; 

- MDS--5-M Coordinator (MMCM) 

- ADM- -Chief Petty Officer (PNC) 

a. Hardware 

Hardware maintenance is performed primarily by a 
Data Systems Technician (DS rating), as explained previously, 
with a Postal Clerk (PC rating) as his assistant. The 
training received by the maintainers was considered adequate, 
as is the technical documentation that they use to carry out 
the maintenance. 

As the duties of the maintainers are collateral 
in nature vice a primary duty, the maintainers did feel that 
it interfered with their primary duties, although the amount 
of interference was not quantifiable or verifiable with the 
System Coordinator. The scope and depth of the preventive 
maintenance performed was considered to be adequate. 

b. System Coordinator and SMS FAS 

The System Coordinator rated the training he 
received from NAVMASSO DETPAC as good, and felt that he could 
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provide adequate training to his relief. Managing the system 
with a group of people on a collateral duty basis was not a 
particular problem. As the System Coordinator, the Assistant 
Supply Officer spent about an hour to an hour and a half each 
day taking care of routine and emergent system- related jobs, 
such as conducting backups, clearing system problems, and 
routine administration. He did not feel that this detracted 
from his primary duties, but he did feel that the System 
Coordinator's workload would increase in the future as people 
became more familiar with the system and made more extensive 
use of it. 

Maintenance and operation of system hardware was 
not a particular problem, and it was felt that the performance 
of the System Management Subsystem (SMS) was good. The 
support provided by NAVMASSO DETPAC and NAVSEACENPAC was 
considered to be very good. 

As the System Coordinator, the Assistant Supply 
Officer was not directly involved in the training or indoc- 
trination of new users. That function was left to the 
individual Functional Area Supervisors and the departments 
concerned. He did feel that the initial training provided by 
NAVMASSO DETPAC could have been more in-depth, although the 
lack of terminals could have had a bearing on that. 

His interactions with the various personnel 
associated with the system, from the CO/XO down to the 
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everyday user, ranged from "not much" to "little or none", 
respectively. Most of the system administration and problem 
solving was delegated to the Functional Area Supervisors, 
c. Functional Area Supervisors 

(1) SFM FAS . The Functional Area Supervisor for 
the Supply and Financial Management module is the Assistant 
Supply Officer, and as such, his views will not be repeated 
here as they have been covered previously under the Supply 
Officer section and the System Coordinator section. 

(2) MBS FAS . The Functional Area Supervisor for 
the Maintenance Data Subsystem is the ship's 3-M Coordinator, 
a Master Chief Machinist's Mate (MMCM) . The MBS subsystem is 
perhaps unique when compared with the other subsystems in 
that every work center on the ship is actively involved in 
data entry and retrieval from it. Because of this, the MBS 
FAS is concerned with input quality and training on a 
ship-wide bas is . 

On the subject of training, the Master Chief 
indicated that he was still in the learning process and that 
he was not yet completely familiar with all the facets and 
components of his subsystem. All of his training as the MBS 
FAS had come from the person he had relieved, and, although 
he regarded the system as "simple", he would not mind having 
some formal schooling on the SNAP-II system. 

As far as training personnel who use the MBS 
subsystem, there was no formalized training instituted. 
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Rather, training was conducted on a "one on one" basis for 
new personnel and others, as required, by the Master Chief. 
Insofar as improvements in the training methodology, the 
Master Chief felt that the addition of some form of "programmed 
instruction" on an interactive basis on the computer terminals 
would be helpful, as would be video-taped programs that could 
be played over the ship's closed circuit television system. 

In the area of system administration, both 
internal and external to the ship, all questions or suggestions 
were forwarded to the System Coordinator for resolution. As 
such the Master Chief reported little or no contact was made 
with outside activities for clarifying procedures or to make 
suggestions for system improvements. 

Rating the documentation for his subsystem as 
adequate, the Master Chief felt that MDS was the best sub- 
system within SNAP-II, and that he and the personnel actually 
using the subsystem for data entry were pleased with the 
results they were obtaining from the system. 

(2) ADM FAS . The Administrative Data Management 
subsystem (ADM) FAS, a Chief Petty Officer (PNC) , regarded 
the system as a time saving device that was tailored to his 
needs. He reported no particular problem in any area of his 
subsystem, and was completely satisfied with what he was 
using. He had no recommendations for changes. 
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C . CASE 3 



1 . Introduction 

One of the first ships to receive SNAP-II, this East 
Coast destroyer (DD) suffered as a result of a rushed instal- 
lation and implementation in January 1985. The ship received 
the standard SNAP-II equipment configuration for a ship of 
her class and size with implementation training conducted in 
January 1985 by NAVMASSO. The SNAP-II system was installed 
just prior to deployment and the training was conducted during 
the transit overseas. The reason for the rushed installation 
was not known to current ship's company. As a result of the 
rushed installation, the conversion from manual to mechanized 
records was less than optimal. Problems arose as the result 
of the ship's inaccurate input to the databases (supply, 
maintenance, and administration) and from hurried processing 
and inadequate quality assurance on part of the contractor 
(SMA) and the Navy shore establishment. 

The implementation training received from NAVMASSO 
was not very effective, due to the preoccupation of shipboard 
personnel with operational and deployment evolutions. The 
system documentation was not able to fill the gap left by the 
inadequate implementation training. 

Figures (1) and (2) in Chapter II delineate the 
standard organization of a surface combatant after imple- 
mentation of SNAP-II. The 3-M Coordinator has been 
designated as the System Coordinator, with an Electronics 
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Technician First Class assigned as his assistant- Maintenance 
on the equipment was performed by Data Systems Technicians 
(DS) . The Functional Area Supervisors were assigned in 
accordance with the directive's of the Type Commander, 
Commander, Naval Surface Forces, U.S. Atlantic Fleet 
(COMNAVSURFLANT) [Ref. ll:p. 4]. 

The ship has experienced a variety of problems with 
the software. The most severe software problems stemmed 
from the rushed implementation and the remainder of the 
software problems could be characterized as growing pains. 

The Supply data base (inventory stock records) , maintenance 
data base (CSMP) , and the Administration data base (personnel 
data) all suffered integrity problems. The source of the 
problems could not be directly linked to any specific action 
but the end result was a lowering of the creditability of the 
system and a reluctance on the part of the users to utilize 
the system. This, coupled with a significant amount of 
downtime (five weeks) caused by equipment failure (power 
supply failed) and a software problem (loading updates) , 
resulted in slowing down the process of bringing the system 
fully in line. 

The ship's personnel have finally accepted the SNAP- 
II system and have put forth an effort to utilize it. The 
SNAP-II system was recognized as a better way of performing 
day-to-day functions. All the functions were not yet on line 
but the ship was heading in that direction. The functional 
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area programs were just starting to be utilized for 
management of resources beyond what was required by the 
system. As an overall management tool, the word processing 
function was the most productively utilized. The BASIC 
language was not being used for programming due to lack of 
programming experience, the delayed acceptance, and the poor 
documentation . 

The training program consists of on-the-job training 
within the functional areas and training of reliefs by the 
incumbent. The command does not have a formal training 
program or indoctrination program for newly transferred 
personnel. The ship does not have an instruction for the use 
and management of the SNAP- 1 1 system. 

2 . Command Perception 

The Commanding Officer was a surface line Commander 
with previous experience on a SNAP- 1 1 ship as the Executive 
Officer. He was not on board during the installation and 
implementation on this ship. The Commanding Officer did not 
personally use the system, but a growing proportion of the 
administrative workload in the ship was being produced with 
the system's v^^ord processing function. He was interested in 
learning to use the system, but he has not received any 
training, and competing operational priorities override his 
desire to learn. The training by NAVMASSO was "implemented 
from the grass roots up and did not reach his level". He 
felt the system was a "good thing and the thing of the 
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future", but as with any new system, it has its share of 
"growing pains". He felt his personnel were using the system 
and learning to use it effectively. 

The Commanding Officer was not aware of the management 
capabilities that the system afforded and did not view it as 
an important managment tool at the command level. Over the 
next several years, he felt Commanding Officers and Executive 
Officers would experience an "education/ training gap" in the 
management of the SNAP- II system, until the current department 
heads with knowledge of SNAP- 1 1 were promoted to the CO/XO 
level . 

The Commanding Officer felt he should not have to be 
involved in the management of the SNAP- II system unless there 
were major problems, and felt that the system did not need 
his guidance or support to achieve acceptable performance. 

He devotes his "time to trouble spots and where he can make 
the most money". 

3 . Middle Level Management and SNAP- 1 1 

The middle level management, for the purposes of this 
review of the SNAP-II system, consists of the Department 
Heads. On board this ship, those interviewed included the 
Combat Systems Officer, the Operations Officer, the 
Engineering Officer and the Supply Officer. The Engineering 
Officer was the only officer without computer training or 
experience prior to this billet. The Combat Systems Officer 
(CSO) and the Operations Officer (OPS) had taken courses in 
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college, and the Supply Officer had prior experience with the 
Navy's Uniform Automated Data Processing System (UADPS) . None 
of these officers had training or experience with the SNAP-II 
system prior to their current billet. 

These officers viewed the SNAP-II system as indis- 
pensable, even though it has had numerous problems. As the 
Combat Systems Officer stated, "it was better than not having 
it on board". The supply and maintenance programs were 
perceived as the most needed, but these officers were most 
dependent on the word processing function. As a group, they 
do not utilize the system as a management tool for planning 
reviewing the operation of their administrative functions. 

The exception to this was the Supply Officer, because of his 
being more dependent on the SNAP-II system in the management 
of his department- - "As SNAP-II goes, so goes the Supply 
Department." All these Department Heads use the system to 
perform routine administrative actions within their functions 
(e.g., approving NAVSUP 1250's or OPNAV 4790/2K's) and for 
word processing. Despite the absence of support from the 
Commanding Officer and Executive Officer, they regard the 
system as capable and expect it to help improve effectiveness 
and accuracy. As the Engineering Department Head stated, it 
was a "better v\:ay of doing the same thing." 

As indicated by their responses, the Department Heads 
do not consider the SNAP-II system as a management tool. 
Although their responses to the interview questions consisted 
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mainly of complaints evolving around day-to-day functioning 
of the programs, the following management issues were raised: 

- Lack of adequate documentation 

- Lack of adequate number of terminals 

- Lack of communication 

- Inadequate knowledge of how to utilize the system for 

management of their functions 

- Functional area management problems 

a. Lack of Adequate Documentation 

The middle level managers found the documentation 
to be inadequate for training new users and of only limited 
use in answering questions or solving problems. They felt 
the manuals were "written for computer literate" personnel and 

not for the novices that make up the majority of the users. 

None of the officers interviewed used the documentation because 
they regarded it as being too hard to understand and difficult 
to use. They rely on their personnel to have the requisite 
knowledge, and more times then not their questions go 
unanswered . 

The documentation did not provide the inter- 
relationships of the various data bases or programs, or flow 
of data through the maintenance and supply subystems. A 
management summary that could provide an overview of the system 
as a whole was cited as a requirement so as to allow the 
Department Heads to effectively utilize the system to manage 
their departmental functions. 

b. Lack of Adequate Number of Terminals 

The middle level managers felt that the number of 
terminals needed to be increased. This would reduce the wasted 
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man-hours they and their personnel spend searching for an open 
terminal or waiting in line to use one. An increase in terminals 
would allow more work to be accomplished during the workday 
when supervisors were present. The problem was partially 
caused by terminals installed in limited access spaces, in 
spaces that were not near the person's work area, and by 
inadequate management of the utilization of terminals. They 
felt that the main reason the problem existed was due to a 
lack of understanding by the shore establishment of the 
environment the afloat personnel operate in. A significant 
number of documents (supply and maintenance) require actions 
to be taken at other than the time the officer was at a 
terminal. This required the officer to stop what he was doing, 
hunt down a terminal, and bump someone else off the terminal 
or stand in line. The alternative was to put the document on 
hold or to create a walk through document, both of which have 
significant repercussions. 

c. Lack of Communication 

The Department Heads felt they operated in a void. 
They had little or no knowledge of the SNAP-II program as it 
existed outside of their ship. They desired to see more 
information on the direction the SNAP-II program was heading 
and what were the major problems the system was experiencing. 

The publications that did exist were inadequate in their 
coverage of problems being experienced by other users. They 
wanted to see the solutions to problems experienced by other 
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users. They wanted to see the solutions to problems experienced 
by other ships or something to indicate that action was being 
taken on problems, and if there were any interim procedures 
that could be employed. 

d. Inadequate Knowledge to Effectively Utilize the 

System for Management of Functions 

As mentioned previously, there was no system over- 
view or management guidelines showing how to utilize the system 
to better manage their functions. The Department Head's per- 
ception was that no thought was given as to how these programs 
affect the management of a department or how the computer could 
be used to improve management of shipboard resources. The 
Supply Officer felt the computer was being used as a "transaction 
processing" system and should be better developed as a management 
information system. They had to grope along without direction 
and had experienced a needless waste of man-hours to gain a 
workable knowledge of their role as users and, more importantly, 
as managers. 

e. Functional Area Management Problems 

The Supply Officer felt that one of the more 
difficult problems encountered during the implementation was 
the lack of functional area knowledge of his personnel. He 
was concerned about the knowledge of the personnel he received 
from "A" School and those personnel transferred from other 
commands. The storekeepers had to be taught basic storekeeping 
before they could perform functions utilizing SNAP-II programs. 
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The maintenance personnel had the same problem in regard to 
preparing the documentation for maintenance actions. 

The Supply Officer and Engineering Officer noted 
that they had been hampered by the lack of guidance from the 
functional area managers (NAVSUP and NAVSEA) . The supply, 

3-M and maintenance manuals did not reflect the policy, 
guidance or procedures to be utilized by shipboard personnel 
in processing supply and maintenance actions with the SNAP- II 
system . 

4 . System Operation and Maintenance 

The 3-M Coordinator was designated as the SNAP-II 
System Coordinator, with an Electronic Technician First Class 
as the Assistant System Coordinator. The Functional Area 
Supervisors were as follows: 

- MDS--3-M Coordinator (EMC) 

- SFM--Senior Chief Petty Officer (SKCS) 

- ADM--Chief Petty Officer (YNC) 

Hardware maintenance was performed by Data System 
Technicians (DS) . The documentation and training they received 
was considered adequate. The hardware maintainers were con- 
cerned about this function taking them away from their primary 
responsibilities, but they have had no significant problems 
with meeting both requirements. The preventive maintenance 
was considered adequate. 

a. System Coordinator 

The System Coordinator did not attend the NAVMASSO 
training due to deployment and the systems manuals did not 
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provide him with the basis for learning the responsibilities 
of the System Coordinator. He felt he could not adequately 
train a replacement and felt it essential that his relief have 
both the 3-M and System Coordinator school prior to reporting 
on board. The System Coordinator felt that utilizing collateral 
duty personnel to run and maintain the system was working well. 

SNAP-II Version 4.00.07 of the software had 
recently been installed. The performance of System Management 
Subsystem (SMS) was considered good, with the support received 
from NAVMASSO and NAVSEACEN considered as outstanding, 
b. Functional Area Supervisors 

The Functional Area Supervisors shared the same 
concerns as the middle level managers about training. The 
primary problems in the training area were: 

- poor implementation training 

- lack of functional knowledge 

- no formal training program on board 

The documentation was rated inadequate for training 
and from poor to acceptable for problem solving/information 
gathering. They felt that a "cookbook approach" to writing 
the manuals was needed. The lack of guidance from Functional 
Area Managers (NAVSUP and NAVSEA) was cited as making day-to- 
day solving of problems more difficult. 

The MBS and SFM Functional Area Supervisors felt 
their programs were very good. They reduced errors and made 
the processing of data more accurate but they did not see a 
reduction in man-hours expended. The man-hours were shifted 
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to other functions or consumed by performing revised procedures. 
The supervisors were divided over whether SNAP- 1 1 increased 
productivity . 

The ADM supervisor felt the program was not a time 
saver for either the yeomen or personnelmen, but the system 
produced more accurate output (shipboard bills, personal data, 
career counselor information, etc.) and the output was easier 
to update. The increase in accurate output was offset by 
increased workload due to an increase in requests for outputs 
and less tolerance for inaccurate or untimely output. The ADM 
supervisor was particularly vehement in emphasizing that the 
system was too slow for any of the yeomen's work to be 
performed with SNAP-II. 

D. CASE 4 

1 . Introduction 

The SNAP-II system was installed on board this Frigate 
(FF) while the ship was nearing the completion of a regularly 
scheduled overhaul (May 1984- January 1985). Without the ship's 
foreknowledge, COMNAVSURFPAC and NAVSEA decided to accelerate 
the ship's SNAP-II installation. The ship, homeported on the 
West Coast, was only given one week's notice prior to the 
installation. The ship received the standard SNAP-II hardware 
configuration for a ship of her class. At the time of the 
interview, version 4.00.07 of the software was being installed. 
The implementation and training were conducted in February 1985 
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by NAVMASSO DETPAC. The records conversion and loading of 
databases were accomplished without significant problems. 

Figures (1) and (2) in Chapter II delineate the ship- 
board organization after implementation of SNAP-II. The 3-M 
Coordinator had been designated as the System Coordinator, 
with an Electronics Technician Chief Petty Officer assigned as 
his assistant. Maintenance on the equipment was performed by 
Electronics Technicians (ET) . The Functional Area Supervisors 
were assigned in accordance with the directive's of the Type 
Commander, Commander Naval Surface Forces, Pacific Fleet 
(COMNAVSURFPAC) [Ref. 12 :p. 4]. 

The ship had experienced only minor hardware problems, 
and had one Casualty Report (CASREP) as a result of a software 
failure, in which the system locked out all users. The casualty 
was corrected with guidance given by NAVMASSO DETPAC via message 
traffic. The support provided by NAVMASSO DETPAC and NAVSEA 
NAVSEACENPAC had been outstanding. 

The SNAP-II system was not fully implemented on board 
and the ship had experienced a significant amount of "growing 
pains" during the transition process. A highlight to the 
process was the ship's effective use of word processing. For 
this ship, the word processing program was the strongest 
mangagement tool in the SNAP-II system. The ship's personnel 
had made no attempt to write software programs using the BASIC 
language provided with the system. This was due, in part, to 
the lack of adequate documentation and training. 
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The ship rated the SNAP- II system "very good" as a 
Transaction Processing System. They were impressed with the 
capability of the supply and maintenance functional area sub- 
systems. Though there were problems, the system was seen as 
having great potential and was highly regarded for its role in 
improving accuracy and timeliness of data. 

The training program consists of on-the-job training 
within the functional areas and training of reliefs by the 
incumbent. The command does not have a formal training program 
or indoctrination program for newly transferred personnel and 
ship does not have an instruction for the use and management 
of the SNAP-II system. 

2 . Command Perception 

The Commanding Officer had been in command for 16 months 
at the time of the interview and had been on board during the 
installation and implementation of the system. He "likes the 
idea of SNAP-II" and "likes what is there," and regarded it as 
particularly useful in the material management arena. "The 
improvement in the quality of the Ship's Force Work List (SFWL) 
and Current Ships Maintenance Project (CSMP) was impressive." 
SNAP-II had "really cut down on the delays" in preparation of 
work packages resulting in "immensely increased validity." The 
SFM subsystem had "bugs in the programs" and they had to 
"maintain dual systems." The SFM subsystem has proved its 
value in the processing of routine paperwork and creating 
reports. In the personnel area, "it (SNAP-II) would be useful. 
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except I lack (an adequate number o£) personnel” to maintain 
the data base. 

Personnel related issues dominated the interviews but 

he felt they were "only part of a bigger problem.” The 

Commanding Officer put it this way: 

The problem is that a ship is tasked to do so many things 
but the number of people never change. Now I've got a new 
computer system with new maintenance and administrative 
requirements. I've got to take care of SNAP- II, but I 
didn't receive additional personnel. It's typical of the 
way we do business. We add, add, add... Nobody takes 
anything away. Then CNO or SECNAV come out with an 
administration reduction program, listing pages of message 
reports that were deleted, but ship's were not making those 
reports . 

The Commanding Officer thought SNAP- 1 1 was a good 
system, but a computer system is made up of more than hardware 
and software. The Commanding Officer, summarizing how he felt, 
stated: 

Where you have good people, SNAP-II performs good because 
your people make it work. Where your people are weak, 

SNAP-II is no better than they are. 

3 . Middle Level Management and SNAP-II 

The middle level management consists of the officers 
in charge of departments. Those interviewed were the Supply 
Officer, the Operations Officer, and the Engineering Officer. 
The Administrative Officer, although not a department head, 
was also interviewed. The Administrative Officer and the 
Engineering Officer did not have training or experience in 
computer operations prior to their current billets. The 
Operations Officer had some computer courses in college but 
did not have practical experience. The Supply Officer was in 
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one of the first groups of Supply officers to receive the 
SNAP- II training offered at Navy Supply Corps School for 
officers going to sea billets. Also, he had been on board a 
destroyer with a Wang VS-80 minicomputer. 

The Department Heads felt the system did not have 
command level support. This hindered the ship in fully 
implementing all the subsystems and had reduced the drive to 
"push the system to its maximum.” 

The Department Heads had high expectations of the 
system, and SNAP-II more than lived up to them. The system 
brings a welcomed reduction in the overburdening process of 
handling paperwork. As the Operations Officer stated, "the 
system was needed and now I do not want to do without it." 

The Department Heads discussed the "management tools" the 
system provides for coping with the day-to-day workload. The 
most discussed were the approval processes for supply material 
requests and work requests, and a variety of word processing 
applications. The word processing was the only program that 
was used for management beyond the day-to-day processing of 
transactions and required reports, 
a. Training 

The implementation training by NAVMASSO DETPAC 
thought the necessary knowledge to the ship to make the SNAP- 
II system operational. However, the training was lacking 
from the management perspective. It did not provide the 
Department Heads with the necessary instruments to manage 
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their functional areas. As the Engineering Officer remarked, 

"I was given a tool and no instructions on how to use it." 

The Department Heads as a group could not perceive what the 
system could do for them as managers, beyond mechanizing the 
manual procedures. Having attended SNAP- 1 1 training and due 
to the deep personal involvement with the SFM subsystem, the 
Supply Officer did have a clearer understanding of the 
management capabilities of SNAP-II. This made it clear to 
him that the system was not "designed with the management 
aspect in mind . " 

The Operations Officer and the Supply Officer 
desired to see off-ship training expanded rapidly. They were 
most concerned about having training for officers. Functional 
Area Supervisors and the System Coordinator prior to reporting 
on board. They stressed the management aspects for officers 
and for the Functional Area Supervisors, 
b. Dependency on the System 

The department heads expressed concern over the 
dependency on the SNAP-II system. It seemed to them that the 
shipboard supply and maintenance, and to a lesser extent the 
administrative system, were heading toward total dependency 
on SNAP-II. The Supply Officer did not feel that the long- 
term effect of SNAP-II on the ship had been adequately studied. 
He was concerned about the effect of downtime on the operation 
and how he would process a sizable backlog with existing 
resources. The Operations Officer wanted a backup capability 
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(redundancy) in the equipment to avoid the possible effects of 
downtime . 

c. Lack of Adequate Number of Terminals 

The Department Heads were troubled by the problem 
of access to terminals. They felt that too much time was 
being spent trying to find an open terminal or waiting in line 
to use terminals. This had a greater affect on the enlisted 
personnel than on the officers. The enlisted personnel mainly 
use terminals for work that must be done. The officers usage 
is more discretionary. The system would be used more frequently 
by officers if they had more convenient access to terminals. 
Though the Supply and Engineering Officers talked of using 
terminals for MDS and SFM subsystem management, the Department 
Heads were stressing the use of the word processing function. 

The suggestion was that greater benefit may be obtained from 
expanding the word processing capability than by increasing 
the management information and decision support capabilities 
of the system. 

4 . System Operation and Maintenance 

The 3-M Coordinator was designated as the SNAP- II 
System Coordinator, with an Electronic Technician Chief Petty 
Officer as the Assistant System Coordinator. The Functional 
Area Supervisors were as follows; 

- MDS--3-M Coordinator 

- SFM--Senior Chief Petty Officer (SKCS) 

- ADM- -Chief Petty Officer (YNC) 
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Hardware maintenance was performed by Electronic 
Technicians (ET) . The training received from SMA was considered 
outstanding. The hardware maintainers felt that the diagnostic 
tape and maintenance manuals were very good and spoke highly 
of the system. One of the maintainers commented, "the system 
is very reliable.” They spoke very highly of the support 
received from NAVSEACENPAC . 

a. System Coordinator 

The System Coordinator rated the training he 
received from NAVMASSO DETPAC as adequate but too limited in 
scope and time frame. He felt he needed more training because 
of his lack of previous computer experience. The COMNAVSURFPAC 
directives proved helpful in grasping the full extent of his 
responsibilities. The System Coordinator thought that his 
relief had to have training prior to reporting to the ship, 
and that the Functional Areas needed to have packaged training 
for use on board the ship. The implementation training the 
ship received from NAVMASSO DETPAC was rated as adequate, and 
software support received was considered "very responsive". 

The System Coordinator and the hardware maintainers 
expressed a desire to have the policy of replacement vice 
repair modified. They had had problems with circuit boards 
and printers that they felt they should have had the capability 
to repair on board but had to be shipped to a central repair 
facility. The ship had been without one of their printers for 
several months with problems that they probably could have 
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corrected, given the proper tools (repair parts, technical 
manuals, training). 

b. Functional Area Supervisors 

The Functional Area Supervisors shared concerns 
about training. The problems cited v\rere: 

- implementation training lacking depth 

- no formal training program on board 

- no packaged functional area training for supervisor 

- personnel lacked adequate functional area knowledge 

- lack of off-ship functional area training 

The Functional Area Supervisors felt they were 
impeded by the lack of guidance on how to handle problems. 
They cited the Naval Supply Systems manuals and the 3-M 
manuals as not having mechanized procedures or guidance on 
how to utilize SNAP-II within those functional areas. The 
Type Commanders have provided the only operational guidance 
that the ship had recieved. 

The Functional Area Supervisors for MDS and SFM 
were very positive about the usefulness and the ability of 
subsystems to save time. The MDS subsystem made maintenance 
management "so much easier and much more accurate". The SFM 
Functional Area Supervisor stated, "the system is good but it 
will be fantastic when the bugs are worked out". 

E. CASE 5 

1 . Introduction 

This Spruance-class destroyer, homeported in Norfolk, 
Virginia, commenced installation of SNAP-II in October 1983. 



90 



By Janaury 1984, it had completed installation and implemen- 
tation of the system. This ship has the standard SNAP-II 
hardware equipment configuration for a ship of her class and 
size. Version 4.00.07 of the software is installed. 

The initial installation of the hardware by SMA and 
the implementation of the software package by NAVMASSO was 
completed with only minor problems. The conversion of stock 
records, outstanding requisitions, CSMP, and COSAL to the SNAP- 
II system contained numerous errors. The faults were later 
determined not to have resulted from the conversion process 
itself, but rather as a result of incomplete original records. 
The COSAL is still not complete. 

The internal SNAP-II organization is structured as 
delineated in Figures (1) and (2) in Chapter II. However, the 
ship has taken a different approach as to the method chosen 
to manage the system. The Command has strong beliefs concerning 
the importance of SNAP-II, resulting in the assignment of an 
officer full-time to manage the SNAP-II system. The 
responsibilities of the System Coordinator and the 3-M 
Coordinator have been assigned to one individual, referred to 
as the "Maintenance Officer". As the XO's direct representative, 
he is responsible for the complete management of the operational 
and maintenance aspects of SNAP-II. The remaining Functional 
Area Supervisors are assigned in accordance with the Type 
Commanders directive [Ref. 11] . 
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Initial training was provided to the Maintenance 
Officer (System Coordinator) and one Hardware Maintainer. 
Following the initial training, the Maintenance Officer spent 
many hours on the system, becoming an expert in all its 
functions and operations. He personally provides continuous 
training to all the users on a one-to-one basis. This has 
increased the knowledge level of the crew, but has not been a 
substitute for formal organized training. 

SNAP- II is in the forefront of the day-to-day 
operations on board this ship. Since it is well organized 
and maintained, a high level of confidence is held in the 
system. The dedication, knowledge of, and support for the 
system provided by the Maintenance Officer is evident and is 
a major factor behind its success. 

As much as the system is utilized, the various 
functions are not completely recognized or used. A perception 
that the system is overloaded, coupled with the lack of enough 
terminals and perceived slow response time are the causes for 
this situation. Hardware performance had been very good, as 
has been the support received from NAVSEACENLANT and NAVMASSO. 

2 . Command Perception 

The Command's support (CO/XO) for the SNAP- I I can be 
characterized as generally positive. However, there are two 
distinct philosophies and views presented by these individuals. 

a. Commanding Officer 

The Commanding Officer, having considerable 
experience in Washington, D.C. (assigned to OP-03) , considers 
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the system as one that possibly should not have made it into 
the fleet in its present configuration. As a member of the 
OP-03 organization, he was very close to the initial con- 
ceptualization and program start-up. He watched the procurement 
process take place and remembers the stages of development as 
it moved through the various political and military process 
enroute to passing its Operational Evaluation and Certification 
(OPEVAL) and finally being introduced into the fleet. His 
views reflect this experience. 

The Commanding Officer was somewhat reluctant to 
press his support beyond the general acknowledgement that the 
system exists and is present on board his ship. He concentrated 
on several broad topics during the interview, addressing 
neither specific hardware nor software oriented problems. He 
personally had removed himself from following the day-to-day 
operations of SNAP-II, and thus did not feel sufficiently 
knowledgeable to comment on hardware or software related 
problems. However, he did comment on the following subjects: 

- failure of program management to recognize inputs from 

the fleet 

- personnel dependency on the system 

- training 

(1) Failure of Program Management to Recognize 
Inputs from the Fleet . The Commanding Officer felt very 
strongly that the system was built without really considering 
what he called "real fleet users inputs." The "real fleet 
users" were defined as the fleet sailors. Division Officers, 
Department Heads, and last, but not least, the Commanding and 
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Executive Officers. He acknowledged that there was a study 
conducted in the form of questionnaires that had solicited 
fleet inputs, but he questioned the use of the results from 
these questionnaires. He felt that the majority of the issues 
addressed in the questionnaire were not included in the design 
of the system: 

The system was bought by people who were not going to be 
the users of the system. They were management types up 
in Washington who lived in data processing and weren't the 
types who were going to sea and use it. They obviously 
had very little respect for fleet inputs. 

(2) Personnel Dependency on the System . The next 

character of the system discussed was the one which the CO 

referred to as dependency. He felt that everyone was becoming 

too dependent on the system, remarking that dependency had 

turned the SNAP- 1 1 system into a huge crutch: 

The biggest problem I see out here' is that it has become 
a crutch. If I want an answer from one of my Department 
Heads or my Division Officers, I get the answer, '\^^ell, 

SNAP's down, can't get that to you right now'. They rely 
on that machine and when the machine's down, you can't do 
it. What a crutch. 

(3) Training . The CO voiced his opinion that plans 
for formal training did not receive appropriate consideration 
and attention during the procurement phase. The reason for 
this, he felt, could be tied directly to the method by which 
the Navy had obtained the system. He believed the decision 

to purchase the hardware from one vendor and then securing a 
second source to develop software broke the continuity required 
to formulate a good training plan, one that would accompany 
the initial implementation of the system. Under these 
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circumstances, the responsibility for development of a 

training plan is not assumed by either the hardware of software 

developer. Consequently, a third party normally has to be 

retained to develop the training plan. This tends to become 

a drawn out evolution, as witnessed with SNAP-II. 

We should have gone out to a firm like IBM and said, look, 
we want a data processing system to meet the following 
requirements. Let them produce the system and software. 

When we got those, we would have had an in-depth training 
program accompanying the system. Why would someone put a 
system into the fleet without providing the proper training 
necessary to support it? We have to get formal training 
to all the potential users before reporting on board. Not 
like we have today. 

However negative the comments by the CO appeared 

toward the system, support was present. Frustration was the 

dominant underlying factor that influenced his support for the 

system. Asked, . . as far as a management tool for you, at 

the Command level, is it providing you any assistance?” 

No, I'm not using it. I don't even want to use it. I don't 
call it up. I have Admin records kept on SNAP, which I ask 
to have delivered to me, but I don't touch the system. 

However, he continued: 

I don't discourage anyone from using it. In fact, all the 
8 O'clock reports and all this stuff comes off of it. I 
don't hold it against them if they don't use it. I don't 
push it. I don't say "why don't you do that on SNAP.” 

I hold them accountable for what they're held accountable 
for as a Department Head. 

b. Executive Officer 

On the other hand, the Executive Officer expressed 
his ideas and concerns from a different perspective. His 
comments reflect the many hours he had spent in direct contact 
with individuals connected with the management of SNAP-II. 



95 



Unlike the CO, the XO v\^as more open and voiced his opinions 
in numerous areas and his perception of the system as a useful 
shipboard tool. 

(1) Program Support . Although not a heavy user of 
the system per se, he considered SNAP-II to be ”a way of life" 
on board ships. He felt that the support, guidance and 
considerations afforded the system from external support 
sources had to drastically change. The Executive Officer was 
concerned that the system is not understood at various external 
commands, those which are responsible for supporting the system. 
He felt they did not have sufficient insight into the functions 
provided by the system and how they should be incorporated 
into the shipboard environment. He was apprehensive that 
these same individuals did not fully understand the impact 
the system had on the way ships are run today: 

You know, everybody thinks it's business as usual. You 
just have a little computer that helps you with your job. 

The Admin of a ship is so different now. I don't think the 
Navy has realized it, but the way you administer a ship 
today with SNAP on it is completely different. 

The bottom line as 1 see it, the Navy just has to accept 
the fact that this is what's going to happen in the future 
and everybody has got to get on board. This is how we're 
going to run ships, and all the outside activities will 
just have to accept that fact. There are some dinosaurs 
out there that don't want to do that. 

Control, as defined by the XO, is the official 
establishment of a central point of contact and responsibility 
for the administrative matters pertaining to a program. He 
feels control has not been defined clearly enough to the fleet. 
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A defined hierarchy of responsibility could not be ascertained. 

He states this naturally results in poor standardization which, 

in turn, affects total support for the system. 

Part of the problem that we see happening with SNAP is that 
the Type Commander doesn't realize what he has here. We 
have NAVMASSO, we got RSG, and we have SURFLANT. No one 
has taken control of SNAP, that's what we see. So 
consequently, every SNAP ship has gone off on its own. 

Standardization is a key link towards the 

future success of SNAP- II. The XO expressed a desire to see 

some standardized guidelines as to just how a ship is supposed 

to use the system. He did not expect a line by line document 

as to the nuts and bolts of operations, but something that 

would define what was expected from the system. If there were 

defined expectations, then maybe the external support units 

could put together a better support package: 

Now that we have a system, we have become dependent by 
virtue of its functions. There still is no control over 
its applications and really just how it is to be used 
in regards to how it is expected to be used. I think 
it resides at the Type Commander. He needs to determine 
how ships are going to be organized . . . organize and 

use this thing. I'm not saying he has to give us some 
black and white plan, but at least give us some guidelines 
that he expects us to follow. The Type Commander should 
come out and say, ok, this is how SNAP ships should be 
set up. This is what we expect the ship to be able to do. 

(2) Training . In the area of training, the 
Executive Officer expressed concern that at the user level, 
there appeared to be little action planned to establish some 
type of formal training. He does not see any one taking control 
and becoming responsible for organizing such training. 
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In fact, one afternoon I called down to NAVSURFLANT, RSG, 
and NAVMASSO to have a meeting down here. They really got 
excited because I looked at them and said, ”0k, who is 
responsible for training?” SURFLANT would look at RSG, and 
RSG would look at NAVMASSO, and NAVMASSO would say, "Wait 
a minute. I'm just an implementer. I don't do anything 
like that." SURFLANT would say, "RSG is our agent for 
training." RSG kind of looked at them and said, "When did 
that happen?" It's simply a forest out there. 

The Executive Officer commented that every 
supply petty officer has to know certain things about SNAP- 1 1 
and that had to be taught to him somewhere, definitely prior 
to arriving on board a ship. The idea of all training on the 
system taking place prior to an individual checking on board 
was also applicable to officers. Once an officer arrives on 
board, there simply isn't enough time or terminals available 
for him to sit down and take a manual, in its present form, 
and learn SNAP-II: 

Training simply has to be implemented prior to arrival to 
make it work. 

(3) Other Issues . The Executive Officer suggested 
numerous other improvements as well as venting his frustrations 
in a constructive manner. The following are some of his 
comments that certainly warrant repeating; 

- SNAP needs improvement in the interface with the shore 
maintenance activities. Still passing paper. We are 
still required to use work packages, run AWR's and carry 
them over. 

- We called up and said, "what are the guidelines for how 
you use SNAP within the supply world?" They replied, 

"Well its in Annex W of our SURFSUP!" We asked, "Where 
is Annex W?" They said, "Well, the draft is on the N7 ' s 
desk." We have had SNAP-II for two years. Doesn't that 
sound sad to you. 
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- One of this ship's major problems now with the system is 
the lack of terminals. Requirements on the use of the 
system have overgrown the amount of terminals that it 
would take to support. 

- What's going to happen to SNAP when a ship goes into the 
yard? I hope someone has a handle on this one. This 
ship is going to a private yard. The contractor is only 
required to provide an ADP system. The ship would like 
to see another SNAP system at the site or take their 
system off to shore. Maybe install it in a van! 

This XO continues to work with the system and 
supports the integration of SNAP- 1 1 throughout the ship. He 
states that he feels the burden, the victories, and the con- 
sequences of failure of SNAP-II more than anyone else on board. 
He summarized his feelings about the system as follows: 

We are totally dependent on the damn thing. A lot of people 
don't realize . . . they think that it's just a computer 

that helps us write messages. They don't realize that our 
whole darn supply system is tied up in it! What else can 
I say? 

3 . Middle Level Management and SNAP-II 

Middle level management, as defined earlier, are those 
officers in the chain of command reporting to the Commanding 
and Executive Officers. In the case of this ship, the fol- 
lowing officers were interviewed: the Combat Systems Officer, 

the Electronic Material Officer (representing the Operations 
Officer), and the Supply Officer. The Engineering Officer was 
not available. 

As a group, these individuals had little experience 
working with computers. The Electronic Material Officer (EMO) 
had experience, owning a home computer which he used 
extensively. He had written numerous programs and was active 
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in a local computer club. On the other hand, the Combat 
Systems Officer and the Supply Officer had virtually no prior 
experience with computers. They acknowledged that computers 
had only existed in their life as a "work" and nothing else. 

No one within this group had received any form of 
training on the system before reporting on board. They had 
only been introduced to the system through the implementation 
briefing given by NAVMASSO. Their follow-on training had been 
through the efforts of the Maintenance Officer. At Surface 
Warfare Officer School (SWOS) , SNAP-11 had only been mentioned 
as a potential system that they might encounter in the fleet. 
No other explanation or in depth briefs had been given. 

a. Supply Officer 

The Supply Officer had only positive remarks about 
SNAP- II. There were numerous problems associated with the 
conversion of stock records, outstanding requisitions, and 
CSMP to the SNAP- 1 1 system, but he remained confident in the 
system. This officer felt that the system was his lifeline 
and if it should go down for any length of time, he would "die 
a quick death". 

In the area of training, he felt that his 
personnel were not adequately trained prior to their arriving 
on board. Interesting to note, he endorsed a higher GCT/ARI 
requirement for SK's enroute to a SNAP- II equipped ship, 
feeling that the SNAP- II system required a higher degree of 

conceptualization versus the former "hands on" manual method 
of supply procedures. 
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b. Combat Systems Officer 

The CSO's comments and views generally were 
addressed to SNAP's use as a word processor and as a system 
to handle his CSMP and supply approval process. He did not 
see it as a management tool. His training so far had only 
been on operating the system to review documents through the 
menu driven mode. He has not found the time nor did he have 
the desire to work through available documentation to increase 
his knowledge of the system. Having to continually go step-by- 
step through the menu-driven programs without an option to 
access directly the function he wanted seemed to him to be 
unnecessary. Although not a heavy user of the system personally, 
the CSO still believed that if the system were to go down for 
any prolonged period of time, his department could not function. 

c. Electronic Material Officer 

The EMO expressed both positive support for the 

system and frustration as to its limited capabilities. As an 

experienced owner and user of a home computer, his use of the 

system was more extensive than the others. He personally used 

the system to adminster his CSMP, produce all of his 8 O'clock 

reports, maintain all his supply/maintenance transactions, and 

made extensive use of the MUSE word processing application. By 

EMO's standards, this system is not very user friendly. He 

made an interesting comment with regard to the system effecting 

his daily routine as a manager: 

SNAP- II is controlling my work instead of me controlling 
it . 
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He considers the system too slow and cumbersome for someone 
with a computer background. 

4 . System Operation and Maintenance 
a. System Coordinator 

The Maintenance Officer (a Lieutenant) performs 
the functions of the System Coordinator, 3-M Coordinator, and 
is the MBS Functional Area Supervisor. He is assisted by a 
Senior Chief Petty Officer (EMCS) . Their role functions are 
the control of maintenance paperwork and the operation and 
maintenance of the SNAP- 1 1 system. The Maintenance Officer 
brought out the following key issues: 

(1) Training . He considered his initial training 
by NAVMASSO as oriented toward preparing him to only help 
someone procedurally through their particular program. Instead, 
he felt it should be reoriented to provide the System Coordinator 
with an understanding of the entire system. He remarked that 

it was essential that the System Coordinator have a good know- 
ledge of all the functions and applications and how they fit 
together to work as a system. 

Training provided for the Department Heads and 
Division Officers was inadequate. The Department Heads and 
Division Officers do not use the system as a management tool 
due to the simple reason that they have not been trained to 
use it as such. They need management level orientation. 

(2) Documentation . Documentation has been compiled 
and written somewhat in the same format as our training plans. 
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It is partitioned into different components and functions. It 
does not bring it together to form a working system. This is 
felt to be adequate for someone who could be classified as a 
simple button pusher but not for someone trying to understand 
the system. 



(3) Excessive Duplication . Excessive duplication 
of efforts are continuing to take place. The requirements for 
hard copies of items which are all available on the system have 
not decreased. Shore establishments have not taken the effort 
to get on board with the fleet. 

In closing, the Maintenance Officer offered 
the following comment: 

The system is great if one had the time to learn it all. 

I'm trying to teach everyone as much as possible as soon 
as possible. Time may solve this problem, but will the 
system survive this (training) crisis? It's a waste not 
to be able to use it to its fullest simply because someone 
has dropped the ball on just what level are we going to 
train. Someone has to get on top of that one soon. 

Ignorance will kill the concept. 

b. Functional Area Supervisors (FAS) 

The Functional Area Supervisor for MBS was the 
Maintenance Officer. His comments can be found in the System 
Coordinator section and will not be repeated here. The Supply 
Officer and a PNl were assigned as the Functional Area 
Supervisors for SFM and ADM subsystems, respectively. 

As a group, the FAS's all expressed total support 
for the system. They each felt that training was inadequate 
and that they only used the system within their area of 
responsibility. They all agreed that the job could be handled 
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in a satisfactory manner on a collateral duty basis. Extensive 
comments or ideas were not voiced by these individuals. "Yes" 
or "very much so" were the general comments when questions 
were asked. 

c. Hardware Maintainers 

The hardv\?are is presently being maintained by two 
Third Class OS's assigned from the Combat Systems department. 

The training provided was characterized as excellent. Both 
individuals felt quite confident in their ability to maintain 
the system. As a collateral duty assignment, they felt that 
they did have sufficient time to handle the additional 
requirements for scheduled PMS and repairs. Each expressed 
excitement about their association with the equipment. 

The only negative aspect detected came in the 
form of frustration for not being allowed to perform maintenance 
in a more detailed fashion. They expressed concern that there 
were numerous conditions that arose and failures that occurred 
that they were capable of fixing if the maintenance concept 
of SNAP- II allowed it. 

F. CASE 6 

1 . Introduction 

The completion of hardware installation in this East 
Coast Spruance - c las s destroyer took place in December, 1983. 

The SNAP- 1 1 System was fully implemented by the end of 
Janaury, 1984. This ship has the standard SNAP-II hardware 
equipment configuration for a ship of her class and size. 
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Version 4.00.07 of the SNAP-II software is presently installed 
and operating satisfactorily. 

The installation and implementation of the system was 
successfully completed during an extended in-port period. The 
success of this was attributed to the excellent implementation 
briefing and initial training provided by NAVMASSO. A 
contributing factor to the success was the number of key 
individuals on board that had exceptional backgrounds in 
information systems. All difficulties encountered during this 
period were promptly resolved by NAVMASSO. 

The system has functioned satisfactorily and the 
support received from NAVMASSO and NAVSEACEN has been excellent 
While on an extended deployment out of CONUS, the system 
experienced a power supply failure and through extraordinary 
support received from SMA and the supply system, a new power 
supply was received and installed in less than 82 hours. 

Support for the system throughout the entire ship is 
very positive. This ship had been a prototype installation 
for the SNAP-II program, designed to identify what requirements 
benefits and problems would be associated with an afloat 
automated information system. As a result, some of the 
personnel on board have retained a personal interest in 
assuring that things were done right the first time. 

A chief petty officer (DSC) , very experienced in the 
computer field and have a B.S. in Computer Science, has been 
assigned as the System Coordinator. An enthusiastic First 



105 



Class Petty Officer (EMI) is assigned as his assistant as well 
as the Functional Area Supervisor for the MDS subsystem. A 
Chief Petty Officer (SKC) from the Supply Department and a 
Chief Petty Officer (PNC) from the Personnel Office are assigned 
as the Functional Area Supervisors for the SFM and ADM sub- 
systems, respectively. The hardware is maintained by a Second 
Class Petty Officer (EW2) and a Third Class Petty Officer (DS3) . 
Both of these petty officers are from the Operations Department. 

Tremendous attention has been given to this system in 
order to assure its continuous operation and support. It is 
used virtually by all levels of the command. Realizing that 
the system is supporting the entire ship's organization, there 
was a display of enthusiasm that permeated the entire ship. 

2 . Command Perception 

The command support given to SNAP- II on board this ship 
was extremely high. Both the Commanding Officer and his 
Executive Officer expressed full support and dedication to the 
system. Although the Commanding Officer had been in Command 
for less than four months at the time of this interview, he 
was quick to point out the significance and the benefits of 
SNAP-II. He was pleasantly surprised to observe the intensity 
with which each manager used the system. 

The Commanding Officer attributed the success of the 
system to the intense efforts expended by the System 
Coordinator. He felt that this individual's experience and 
talent had paved the way for others to expand their knowledge 
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and use of the system. Having an experienced System Coordinator 
in charge of the system gave the CO a feeling of enormous 
confidence in the system. 

Generally, the Commanding Officer expressed a great 
degree of satisfaction with the system. Though enthusiastic, 
he was not sure as to how he would personally use SNAP-II, if 
at all. He had a terminal in his cabin but had not used it, 
nor did he anticipate using it. However, there were a few 
areas in which he did voice concern. 

a. Training 

In the area of training, he was disappointed in 
what he believed to be the failure of the shore establishment 
to support SNAP-II. He cited a case of sending his 3-M 
Coordinator to school and finding that SNAP-II was not even 
mentioned. He was frustrated that time and effort had been 
spent to send this individual to school and SNAP-II was not 
taught . 

b. Standardization 

After becoming aware that there were some minor 
problems associated with the system, the CO attempted to 
organize a cross talk program with other ships within his 
squadron. He quickly discovered that this was not productive 
because each ship had implemented SNAP-II in a different 
manner. There was no standardization, no uniformity in depth 
and breadth of system use and application. 
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The Executive Officer reflected the majority of 
the comments made by the Commanding Officer, He did note that 
SNAP-II had become the routine way of doing business and all 
activity would come to a stop if the ship experienced a 
casualty to the system. On the negative side, he felt that 
overall support from the shore establishment was at least two 
to four years behind the activities of the fleet. 

3 . Middle Level Managment and SNAP-II 

The middle level managers interviewed were the 
Operations Officer, Supply Officer, and the Engineering Officer. 
The Combat Systems Officer was not available for comment at 
the time of the interview. Within this group, only the 
Supply Officer had any previous experience working with any 
form of ADP. He had been in numerous billets associated with 
various ADP systems and had been assigned as the SNAP-II 
Program Officer on a Type Commander staff. The remaining 
officers had been exposed to the SNAP-II system only since 
reporting on board this ship. 

As a group, these officers voiced practically the 
same views concerning their likes and dislikes with the system. 
They all expressed the feeling that the system was designed 
to be utilized more by Division Officers and assistants than 
by the department heads. They felt the system did not provide 
the information they needed to perform their jobs. They were 
not heavy users of the system, using only the word processing 
capabilities and the functions which required them to review 
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the various maintenance and supply actions. These officers 
commented that their enthusiasm to expand their use of the 
system was hampered by the fact that they had not received any 
formal training on the system. Each one commented that they 
did not have the time to devote to learning the system once 
they had reported on board, relying instead on their division 
officers and assistants to perform subsystem functions. Each 
stated that they were comfortable only with using the system 
as a word processor and to review maintenance and supply 
actions. Since the Department Heads had not developed con- 
fidence in the system, they continued to maintain duplicate 
hard copies on data held in the system. 

As a result of having the system on board, each middle 
manager expressed the belief that he certainly expected a more 
complete and better quality product from his subordinates. 
Since it was relatively easy to edit their input and correct 
mistakes, error free documents were expected. 

4 . System Operation and Maintenance 

The System Coordinator had reported on board without 
having any prior experience with or knowledge of SNAP- II. He 
did, however, bring with him 12 years of experience from 
working closely with computers in the Naval Tactical Data 
System (NTDS) , as well as a B.S. in Computer Science. He has 
attended the System Coordinator course conducted by NAVMASSO 
prior to implementation of the system. 
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The System Coordinator voiced his assessment of the 
system in broad terms, commenting on the following topics: 
installation/implementation, support evaluation, training, and 
general overall software evaluation. 

a. Installation/implementation 

During the installation and implementation phase, 
the ship received excellent briefings on what was going to be 
installed and how it was going to take place. At no time was 
the ship asked to comment on what was going to happen to their 
ship. "Here is what you are going to get, this is how we are 
going to install it, and this is where the components are 
going to be placed" was the order of the day. The System 
Coordinator felt very strongly that the ships should have the 
flexibility in determining where the terminals should be 
installed . 

b. Support Evaluation 

The support and attention provided to the system 
by NAVMASSO and the Type Commander was considered to be 
outstanding. When there were problems with the software, 
NAVMASSO responded almost immediately. The response to 
CASREPS was excellent, and software problems were resolved 
through message traffic in an expeditious manner while the 
ship was deployed. 

c. Training 

Training was considered to be inadequate at all 
levels. However, he did think that a considerable amount of 
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training could be accomplished on board our ships if there was 
a Navy-wide plan that would standardize the overall training. 
The System Coordinator felt that instituting a PQS program 
would go a long way in achieving that goal. Although the 
System Coordinator was orienting his comments concerning 
training toward the enlisted personnel, he felt strongly that 
there should also be a formal training plan established to 
provide the Department Heads and Division Officers a management 
oriented approach to the system. 

d. Software Evaluation 

The software as presently designed was considered 
adequate for a user that has to take a step by step approach 
to any application. As the experience level of individual 
using the system increases, this approach will become time 
consuming and will be considered elementary, creating a feeling 
among users that the system is becoming obsolete and decreasing 
in its value as a useful information system. It will then 
become annoying to work with the system as it is presently 
designed, thus relegating it to transaction processing only. 

In summary, the System Coordinator is a very 

enthusiastic individual who feels that the system is the way 

of life today on board his ship. His final comment was: 

The system is an excellent one, but first we all have to 
learn how to use it before it will become acceptable. 

The Functional Area Supervisors had very little to 
say about the system. They all supported the system and 
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expressed that it had received positive support throughout 
the entire command. Since the System Coordinator took it 
upon himself to perform essentially all the duties that were 
normally assigned to the Functional Area Supervisors, they 
remained somewhat aloof and accepted this status quo. 
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V. SUMMARY OF CASE STUDIES 



The previous chapter presented the views o£ shipboard 
personnel who have been operating with the SNAP-II system for 
at least one year. Their perspectives and opinions have been 
developed through constant association and experience with 
the system. 

The following summaries present a synopsis of the main 
issues identified by the individual ships as having had an 
impact on the integration and use of the SNAP-II system 
within their organizations. Also included are summary 
evaluations by the authors as to the general extent to which 
the SNAP-II system have been assimilated by the ships, based 
on the interviews and through observation. 

A. CASE 1 

1 . Evaluation of Ship 

Stated briefly, this ship has transitioned successfully 
to the SNAP-II system and personnel are finding new and in- 
novative ways of adapting it to their organization. Users at 
all levels of the ship are very pleased with the system and 
are using it extensively. 

Management is using the system as a tool rather than 
relegating it to use at the lower echelons as a data entry 
and transaction processing system. 
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The ship is pleased with the performance of the hard- 



ware, and had not encountered major problems in the concept 
of using collateral duty personnel to manage and maintain the 
system. Support provided by NAVSEA and NAVMASSO was regarded 
as very good. 

Evident through observation and as a result of the 
various interviews, the ship had several strong qualities that 
positively influenced the implementation of the SNAP-II 
system: 

- a strong commitment to excellence in the first place 

- personnel with backgrounds in computer systems available 

to help guide the transition 

- strong involvement of the middle level managers in the 

transition 

2 . Significant Issues 

The specific items of concern raised by the ship's 
personnel and regarded as significant were as follows: 

- Inadequate documentation for the various levels of system 
users. This was raised from several perspectives, 
including lack of readability and the absence of different 
perspectives and levels of documentation (i.e. not every- 
one can effectively use a data-entry user's "view" of the 
system to understand and use the system) . 

- Training was brought up as a problem, not in the area of 
initial training, but in the context of "continuing 
education" for on board users in the future, and from 
the viewpoint that formal schooling should be made 
available to the Functional Area Supervisors (and possibly 
lower level users) in addition to training presently 
available for the System Coordinator. 

Although not specifically alluded to during the 
interviews, there were two further areas of interest evident: 

- After implementation of the SNAP-II system, the ship was 
not reviewed or audited by program management to find out 
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how the system was working. There was no positive action 
to find out if there were problems integrating the system, 
only reaction to specific problems reported by the ship. 

- There is a lack of understanding of how the program is 
set up and managed ashore. Because of NAVMASSO's close 
involvement in the conversion and implementation of the 
system, the ship regards them as the focal point for 
dealing with SNAP- II problems and suggestions. In some 
cases this is true. Otherwise, there is little official 
communication on project status, improvements, or hov\f 
the project is being handled on a Navy-wide basis. 



B . CASE 2 

1 . Evaluation of Ship 

Implementation of the SNAP-II system in this ship has 
been successful at the lower levels (data entry personnel) , 
but has not been put to great use by the middle level managers. 
At this level, it appears that the system is regarded as 
something to be contended with, and as such is not used as a 
management tool . 

While the system is appreciated and fully backed by 
the command, and the data entry personnel are having no problem 
using the system, there is a "gulf, or void in the middle 
where the system is accepted at face value only. There is 
apparently a lack of understanding as to how to incorporate 
the system so as to derive its benefits. 

The reason for the above is not a lack of positive 
atmosphere in the command. The benefits derived from the 
system are fully appreciated throughout the ship, but there 
has been no movement to expand the use of the system or 
develop new methods to incorporate it as a management tool. 
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The reasons for the above appear to be: 

- lack of adequate training or "selling of the product" to 

the middle level managers 

- the documentation is regarded as difficult to assimilate 

- system capabilities are not fully understood by system 

management personnel -- the system coordinator and the 
functional area supervisors 

The ship has had few problems v^?ith the hardware, and 

support of the system by NAVSEA and NAVMASSO has been good. 

2 . Significant Issues 



Specific items of concern raised by shipboard personnel 
include the following: 

- documentation not aimed at management and difficult to 

understand 

- inability to derive useful information that can be 

utilized by management 

- the effect on management style by the introduction of an 

automated information system 

- the adequacy of the number of terminals on board 

An additional point made by the Commanding Officer was 
that until this survey had been conducted, no one external to 
the ship had come aboard to inquire about the status of the 
system and how the ship v\ras using it. 



C. CASE 3 

1 . Evaluation of Ship 

The hurried manner in which SNAP-II was installed 
and implemented had a lasting effect on the performance of 
this ship. Compounded by significant downtime shortly after 
implementation, the personnel lost confidence in the system 
resulting in a slower rate of progress in bringing the system 
on line. The neutral command support adversely affected the 
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drive of the personnel to utilize the system and has resulted 
in the ship still not performing all subsystem functions. 

The ship's personnel are gaining confidence in the 
system and have started to effectively use the system for 
management of daily operations. The middle level managers 
still do not have a management perspective on how to utilize 
SNAP-II. They perform those functions that are mandatory but 
do not seek to understand the potential of the system in 
assisting them in managing their functions. 

Ship's personnel are impressed by the system's 
capability to perform routine work and think that despite 
its shortcomings, it has reduced the administrative burden. 

As the Combat Systems Officer stated, it's "better than not 
having it on board." 

2 . Significant Issues 

The interviews with ship's personnel uncovered a 
myriad of problems, suggestions and complaints. The following 
issues surfaced as being the most significant; 

a. SNAP-II needs to be more fully developed as a 
management information system and the ship's command and 
middle level managers need to be trained in the effective use 
of the system as a management tool. 

b. The shipboard and shore establishment personnel 
need to broaden their perspectives on the effect SNAP-II has 
on shipboard routines. It is currently being thought of as 

an aid to management. It will become the "management system." 
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Administratively speaking, the ship will succeed or fail by 
how they utilize SNAP- II. 

c. The lack of access to terminals hinders effective 
use of the SNAP- 1 1 system and wastes precious manhours. 

d. Documentation and guidance manuals need to be 
improved or reflect guidance for managing with the SNAP- 1 1 
system. Documentation is inadequate for training new users 
and of limited value in solving problems. Guidance in using 
NAP-II from the Functional Managers (e.g., NAVSUP Manual P-485, 
OPNAV 5-M Manuals) is nonexistent. 

D. CASE 4 

1 . Evaluation of Ship 

This ship's approach to management is to manage by 
exception and do only what has to be done. In one word, 
"survive". The command does not foster the use of SNAP-II. 

The lackadaisical approach to the effective utilization of 
the capabilities of the system leaves subordinates with little 
enthusiasm to make the system perform effectively. Currently, 
the system is not fully implemented and various functions are 
not utilized. 

The ship views SNAP-II as merely a transaction pro- 
cessing system and SNAP-II is not utilized to better manage 
their functions. The ship has just replaced a manual system 
with a mechanized system without reaping the benefits of 
automation. They do feel it has greatly improved the accuracy 
and timeliness of data and has proved its value to the ship. 
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2 . Significant Issues 



The following issues came to the forefront: 

a. SNAP- II system's management capabilities need to 
be expanded and the ship's managers need training in how to 
effectively utilize these management capabilities. 

b. Training needs to be improved in the following 

areas : 

- depth of implementation training 

- packaged training for Functional Area Supervisors (FAS) 

- Off-ship training needed for CO/XO down to the FAS level 

- functional area (rate) training needs to be strengthened 

c. The number of terminals need to be increased to 
reduce man-hours expended waiting for terminals and to expand 
access for management uses. 

E. CASE 5 

1 . Evaluation of Ship 

The installation and implementation of SNAP- II was 
conducted in an orderly and expeditious manner, however, the 
conversion of stock records, outstanding requisition file, 
CSMP, and COSAL experienced considerable difficulties. It 
could not be determined if the discrepancies resulted from 
the conversion process or were present in the original records 
prior to conversion. 

The Command demonstrated a positive attitude toward 
the system. There were some perception differences between 
the Commanding Officer and the Executive Officer; the CO was 
frustrated due to the way he perceived the procurement process 
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to have taken place, feeling that it had resulted in a system 
designed without including input from fleet users. This had 
resulted in a system that was introduced without providing an 
accompanying Navy Training Plan. The Commanding Officer does 
support the system and desires to see it improved to a point 
that it can become what he considers a management tool. On 
the other hand, the Executive Officer sees it as the way the 
Navy has chosen to institute on board automated information 
systems. Therefore he continually strives to make it work. 

Unlike other ships interviewed, the Command chose to 
take a different approach as to the management of the system. 

It was felt that the importance of the system justified the 
assignment of an officer full time to manage the operations, 
maintenance and training for the SNAP- II. 

The middle managers were all supportive of the system 
and welcomed its contribution in relieving their administrative 
burdens. They all voiced their opinions that if they had 
received formal training, they would be making better use of 
the system. 

2 . Significant Issues 

The following issues surfaced as being the most 
s ignif icant : 

- training is not available for personnel prior to reporting 
on board, lacks a management perspective, and there is no 
action on implementing the Navy Training Plan 

- inadequate number of terminals 

- lack of program support in the form of program guidance, 
standardization on board ships, interface with external 
commands, and knowledge of impact of SNAP- 1 1 on ship 
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- developing the system as a Management Information System 

- documentation lacks a management perspective 

F. CASE 6 

1 . Evaluation of Ship 

This ship enjoyed a successful installation and 
implementation of the SNAP-II system. The hardware and peri- 
pherals have performed satisfactorily, creating respect and 
confidence in the ability of the system to perform required 
functions. The only comments concerning hardware were in the 
form of requesting more terminals. 

The system is operating as a very successful transaction 
processing system. There is a considerable amount of computer 
knowledge available among several key individuals. This no 
doubt has contributed favorably to the success of the initial 
transition as well as the continuous operations of the system. 

At the Command level, there was a very positive attitude toward 
the overall system and one sensed a feeling of dedication 
toward the future success of SNAP-II. They see a great amount 
of effort going into the system and in turn see the benefits 
it returns. Overall, management has commented that the SNAP-II 
system had been accepted as the way of the future for the Navy 
in regards to ADP on board ships. It is performing adequately, 
but no one really knows where they are going with it. 

The use of the system has not reached its full potential. 
The middle level managers commented that they were not 

expanding their use of the system to the point whereby it would 
become useful as a mangement tool because they: 
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- had not been afforded the necessary training prior to 
arriving on board to effectively use the system as a 
management tool 

- did not have the time once arriving on board to devote 
sufficient time to learning the system well enough to be 
able to use it as a management tool 

- Division Officers and their subordinates were the real 
users of the system, not Department Heads 

At the levels below the Department Heads, the system 
is being used extensively. The Division Officers maintain 
the majority of their required administrative records and 
files on the system. It was stated that this has provided 
them a more effective and efficient vvfay to manage their 
division . 

2 . Significant Issues 

There v\:ere several areas of concern which were 
identified : 

- Support was not being provided to the fleet in the form 
of recognizing the present need to include SNAP-II 
training in various schools. 

- Training should be provided to all levels of users prior 
to reporting on board. 

- Standardization is lacking in the depth and the breath 
of the use of SNAP- II. 

- The system has become the routine way of business and 
that the overall support for the system from shore 
establishments is two to four years behind the fleet. 

- A PQS program needs to be developed for the various 
levels of users. 

- There is an inadequate number of terminals. 
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VI. ANALYSIS AND DISCUSSION OF CASE STUDIES 



The issues that emerged from the ship reviews will be 
presented in two different sections: an overview analysis of 

the case studies will be done, and from these, a discussion 
of specific items that transcended the various issues in the 
case studies. 

A. PROGRAM PERSPECTIVE AND GENERAL ISSUES 

Program management is defined, for the purposes of this 
thesis, as all commands external to the users command that are 
involved in the procurement, outfitting, installation, imple- 
mentation and operation of the SNAP-II system (Chapter II 
presented an overview of the program management organization) . 
In addition, those external commands that directly support the 
ship's supply, maintenance and administrative functions (e..g.. 
Naval Supply Centers, Fleet Accounting and Disbursing Centers, 
Ship's Intermediate Maintenance Activities, Destroyer Tenders, 
Navy Finance Center) are included when discussing the interface 
between SNAP-II and the shore establishment. 

The value of any system ultimately rests in its acceptance 
by the user. User satisfaction is the key determinant when 
discussing any system's benefits. Across the board, the SNAP- 
II system is viewed as a tremendous benefit to the ships in 
the performance of those functions that have been mechanized. 
Although user satisfaction appeared to be high, there was a 
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considerable amount of frustration in regard to various aspects 
of the system. From the afloat vantage point, SNAP-II could 
be significantly better than it is today. There were numerous 



problems cited and issues raised, that, when viewed in totality, 
had a common root insofar as the ships were concerned: pro- 

gram management. This may be a misconception on their part, 
but there is a certain level of disenchantment with the way 
the program is being managed. In and of itself, this is 
indicative of a need for increased and effective communication 
with the fleet user. 

On closer observation, the satisfaction and enthusiasm 
for the system was mainly at the functional area supervisor 
level. Their enthusiasm appears to be due to the newness of 
system and the advantages of a mechanized approach over a 
manual approach. The impression is that as these users become 
more sophisticated, they will be less willing to accept the 
problems they have encountered, and if the problems persist 
or recur, their enthusiasm will wane. 

The ship's managers, on the other hand, are less satisfied 
with the system. They feel for the most part that SNAP-II 
does not address their needs as managers. Although it does 
provide them the ability to manage specific operations, it 
does not lend itself well to overall management of their 
department or area of responsibility. 

At the command level, the system is of little use as a 
decision making tool, and as such is ignored. The system was 
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not regarded as being able to provide answers to ad hoc 
questions. Although some o£ the Commanding Officers and 
Executive Officers give the system high marks in the area of 
performance of specific tasks and management review of them, 
none felt that it was of use to them in guiding the ship 
toward mission accomplishment. As one CO pointed out, SNAP- 
II was just another way of doing the same job. 

The various ranges and depths indicated in the summary 
Chapter V gives an indication of the problem associated with 
assessing the status of SNAP-II on board a particular ship. 

Due to a lack of standardization, each ship has employed SNAP- 
II in a different manner, depending on the importance the 
command (CO/XO) attached to SNAP-II, the command involvement 
in the management of the system, quality of "available" 
personnel, location of the hardware on board, and many other 
factors peculiar to a specific ship. Ships are at different 
levels of utilizing the system as a whole. Kroenke has cate- 
gorized computer systems according to how they are employed in 
the management of an organization [Ref. 14;pp. 91-94]: 

- Decision Support Systems - provides for ad hoc manipulation 
and handling of data; irregular or one time queries for 
information can be handled 

- Management Information Systems - provides past, present 
and future information; generates preformatted reports 
to facilitate management decision making 

- Transaction Processing System - receives and records 
changes to a data base, and produces appropriate documents 

Some ships are basically capable of effectively utilizing the 

system to process transactions, while others are using the 
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system to manage the transaction processing, and there are 
those that are pushing their use of the system towards the 
MIS arena. This situation is exacerbated by having each 
subsystem employed at different levels within any ship. 

Though the comments received were for the most part 
localized to a specific problem area, there were a number of 
significant issues raised that apply to overall management of 
the program. The ship's have serious questions in each of 
several management support areas that drive home the user's 
impression that SNAP- 1 1 planning was not well thought out and 
management has not been coordinated. 

In this context, management support has been divided into 
the following six broad areas: 

- direction of program 

- guidance provided 

- hardware/software support 

- training 

- communication 

- interface with shore establishment 

Though these areas are arbitrary and do not relate to any 
charter or list of responsibilities, they serve to focus in 
on the major concerns the ships have with the SNAP-II system. 
Each area will be discussed and the significant issues (from 
the ship's viewpoint) will be brought out. [Authors note: 
System management terms have been utilized to concisely convey 
the intent or meaning of what various personnel felt and said-- 
obviously, they did not use them themselves.]. 
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1 . Direction of Program 



The overall direction o£ the SNAP- II program, from the 
ship's perspective, is to mechanize manual functions in the 
supply, maintenance and administrative areas. They do not 
necessarily view it as an effort to reduce the administrative 
burden on ships, and few of the middle level managers inter- 
viewed saw it as an attempt to provide management capabilities 
in performing their functions. The system is viewed mainly as 
a Transaction Processing System with minimal management capa- 
bilities, providing only those management capabilities 
necessary to manage specific operations. It is not perceived 
as a Management Information System (MIS) or Decision Support 
System (DSS) , but the Command level and middle level managers 
feel that it should perform at least at the MIS level. 

The two issues that weighed most heavily on the minds 
of the interviewed personnel were: the lack of project review 

by program management at the ship level as a tool to guide 
the direction of the program, and whether SNAP- II was intended 
to be a Transaction Processing System, Management Information 
System, or a Decision Support System. The issue of lack of 
project review of ships with SNAP-II installed will be 
discussed in the following section on specific emergent issues. 

The issue of SNAP- II 's purpose as a system originates 
from the discontinuity between the phrases used to describe 
the goals and attributes of the SNAP-II system (e.g., real- 
time MIS [Ref. l:p. 1]. Automated Information System [Ref. 
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3:p. 1] and the reality of what the system can do, or more 
importantly, what it cannot do. The managers feel that 
program management does not understand the needs of the fleet 
with regard to the output the system should provide. 

If it is assumed that SNAP-II is a management system, 
then there appears to be a dichotomy between its purpose and 
the amount of hardware provided to accomplish this. Namely, 
with the word processing capability and the management function 
superimposed on the transaction processing system, the number 
of terminals appear to be inadequate to handle the management 
function. As the case summaries showed, every ship felt that 
they did not have an adequate number of terminals to perform 
the functions within SNAP-II. The transaction processing and 
related day-to-day actions by managers took priority and sub- 
system management uses and word processing were relegated to 
a "catch as catch can" status. As a group, the middle level 
managers felt word processing was an important management tool, 
yet they could not use it to its fullest extent due to the 
effects it had on system performance (response time) and 
transaction processing. 

2 . Program Guidance 

For the purposes of this review, program guidance 
covers the implementation and operational guidance received 
from external commands. This does not include the training 
of personnel, as that will be covered in a separate section. 
Although each ship felt program guidance was inadequate, this 
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area was not considered a key issue in and of itself, but was 
in the background of most emergent issues. It is discussed 
because it serves to provide a background that is relevant in 
other areas that were identified by the individual ships. 

As stated in various cases, the implementation process 
that NAVMASSO oversees is considered to be good by the ships 
reviewed, and was not a major issue except as it related to 
documentation and training. These two issues will be discussed 
in the next section on specific emergent issues. 

The operational guidance which is within the purview 
of the ship's chain of command and the supporting shore 
establishment (refer to Figures (3) and (4) in Chapter II) was 
considered as inadequate or non-existent. The Type Commanders 
were the only bright spot in the process. They have provided 
guidance, but, as with any new program, it was not timely or 
in sufficient depth. The Executive Officer of a destroyer 
noted that the ship had been waiting "two years" for the 
guidance that the "Annex W of SURFSUP" was going to provide. 

Unlike the Type Commanders, the shore establishment 
has not provided guidance on how to effectively integrate 
SNAP- 1 1 into the shipboard routine. The functional managers 
have not updated basic publications (e.g. NAVSUP Manuals, 5-M 
Manuals) to include policy or procedural guidelines. Some of 
the ships have had SNAP- II on board for two years and are 
still waiting for this basic guidance. 
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5 . Hardware and Software Support 

The ships did not report many problems with the 
hardware and it was considered very reliable (Chapter HI pro- 
vides background information on hardware and software) . 

Another bright spot in the whole program is the support the 
ship receives in the maintenance of hardware and software. As 
noted in each of the cases, the performance of both NAVSEACENS, 
NAVMASSO, and NAVMASSO DETPAC has been outstanding in the area 
of response to problems and questions. As documented in Case 
Five, ships had stories of superlative effort put forth to 
support them when they needed it. The software, although 
there were numerous problems, was not a major issue to most 
ships. The users had a tremendous number of suggestions to 
improve the subsystems and identified numerous problems with 
programs (all at the procedural level). No major problems 
were cited that had not previously been identified by NAVMASSO. 
As stated previously, the users at the lower levels are 
impressed with the functions performed by the software. 

The issue that dominated any discussion of software 
was that of documentation. Documentation was considered 
inadequate for training and of little value for problem 
solving and as a general reference. Documentation will be 
discussed in greater detail in Section B of this chapter. 

4 . Personnel and Training 

The subject of personnel was not a major issue, other 
than as it related to training (Chapter III provides 
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background information on personnel and training) . The 
concept of using collateral duty personnel to run and maintain 
the SNAP-II system, with exception of relatively few comments, 
was felt to be sound. Although a number of system coordinators 
and maintainers felt that it could affect their primary 
functions, no data or documentation was provided to support 
their feelings. It is felt that there will be incidences 
where it will affect the support of SNAP-II, but they do not 
warrant a change in policy at this time. The most frequently 
discussed issue and the one with the most immediate concern 
was training. Their criticism of program management crystal- 
lized with the topic of training. Training will be discussed 
in Section B of this chapter. 

5 . Communication 

The area of communication was not the subject of much 
discussion by itself, but was linked to almost every other 
issue that surfaced. To that extent, it is an underlying 
cause of, or a result of each issue that the ships surfaced. 
From the afloat viewpoint, there is a lack of communication 
at all levels and in all management areas of the SNAP-II 
program. The issues raised were; lack of fleet input, lack 
of dialog with the fleet on matters concerning operations, 
and the lack of understanding of the program's decision 
making process in the fleet. 

Most of the managerial personnel feel that the program 
got off to a bad start as a result of a lack of good fleet 
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input or input that appeared to be ignored by the program 
management (Case Six presents a good example of this view} . 
Instead, program development was controlled by personnel who 
were too far removed from the realities of shipboard life and 
who relied on manuals to provide the necessary guidance. To 
managerial personnel, the system was not developed to meet 
shipboard needs as they view it. 

Until recently, there was little effort to have a 
dialog with the fleet concerning the problems and issues they 
have, or to provide them information on the status of problems 
or expected changes to the system. There is little in the 
way of public relations concerning SNAP-II aimed either at the 
ships or at the shore establishment. 

The cases disclosed that the fleet has very scant 
knowledge of the infrastructure of the SNAP-II program and 
little information on the decision making process. To the 
ships, the SNAP-II program is embodied by NAVSEACEN and 
NAVMASSO, with the TYCOM playing its traditional role of 
monitoring the problems associated with SNAP-II. From the 
end user viewpoint the power to make decisions rests with 
NAVSEA for hardware and NAVMASSO for software and all other 
concerns . 

6 . Interface with Supporting Shore Establishment 

The interface consists of the way in which the ship 
and the supporting shore establishment pass requirements and 
information. The issue here lies with the way the external 
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activities provide services or assistance. This interface is 
in the manual mode and not prepared to handle the mechanized 
output from SNAP-II. This problem has been noted by several 
of the ships visited. Specifically, the maintenance activities 
(e.g., dealing with work packages, RAV) , supply activities 
(e.g., dealing with requisition processing, status on pro- 
curements) and financial activities (e.g., dealing with 
processing of obligations, reconciliation of expenditures) 
cannot or do not accept the mechanized output of SNAP-II. 

These activities are, for the most part, in the manual mode 
of communicating with ships. 

Another shortcoming of the system is the lack of use 
of telecommunications to support the ship while at sea and 
while in port. On board ship, various processes could com- 
municate directly. For example, it is archaic to create an 
outgoing message on SNAP-II, punch a paper tape, carry the 
paper tape to radio central to be fed into a machine to be 
transmitted off the ship. Also, the ship does not have the 
capability to communicate directly, via telephone lines, with 
supporting activities when it is in port. 

B. SPECIFIC EMERGENT ISSUES 

The previous section gave an overview and analysis of the 
issues raised by the ships. This section will focus on those 
issues that have had the greatest impact on the integration 
of the SNAP-II system and transcend many of the issues raised 
by the end user. 



133 



Project Review, Management Policy, and Standards 



1 . 

Management policy for the use [vice management of) of 
SNAP- 1 1 system was an item of concern in many of the ships 
reviewed. The subject of project review, although brought up 
only as a tangential issue in several cases, in and of itself 
was nevertheless conspicuous by its absence. These two issues 
are closely related, as the review process must have some 
standard to be compared with, and these standards are driven 
by policy decisions. As one Commanding Officer noted, the 
interviews herein v\:ere the first time someone external to his 
ship had been aboard specifically and formally to inquire as 
to how the various aspects of SNAP- II were performing in his 
command . 

a. Need for Project Review 

Any computer project has risks. Among other 
definitions, risk is defined by Cash, et al [Ref. 15:p. 313] 
as : 

- failure to obtain all, or even any of the intended benefits 

- increased costs of implementation 

- longer time for implementation 

- technical performance of system below estimates. 

To reduce the risk inherent in any project, proper 
management tools must be brought to bear to control the project. 
From a systems point of view, Senn defines a control model 
as [Ref. 16: pp. 12-13]: 

- a standard for acceptable performance 

- a method of measuring actual performance 

- a means of comparing actual performance against the 

standard 

- a method of feedback. 
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Senn further categorizes the formal process of determining how 
well the system is working, how it has been accepted and 
whether adjustments are needed as "post implementation review” 
[Ref. 16:p. 542]. In this context, "post implementation 
review” can be regarded as a feedback method to determine if 
the actual installed and working computer system is doing what 
it was designed to do. A case study advanced by Cash et al 
[Ref. 15:p. 357] places post implementation review as part of 
the control and monitoring process, which is analogous to the 
system feedback concept. 

As established, the only feedback provided for in 
the current SNAP-II program is a reactionary one--i.e., ships 
generate reports describing trouble with hardware or software, 
or suggesting changes to some aspect of the system. While 
there is informal liaison maintained by NAVMASSO implementation 
personnel after installation, there is no formalized or "active” 
review process. Periodic meetings are conducted on a geo- 
graphic basis to discuss system problems or new developments, 
with fleet attendance highly encouraged, but not mandatory. 
"Technical Advisories” and "Fleet Bulletins” are also 
published by various sources. 

A post implementation review can be used as feedback 
to improve system effectiveness and attain the bottom line of 
user satisfaction. Various authors have outlined both the 
need for post implementation reviews and the general character 
they should take. Gaydasch has formulated what he terms a 
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"quick and easy approach" to this process [Ref. 17:pp. 54-55], 
maintaining that the review, or audit, should be performed 
after the system has had a chance to "settle down". The general 
outline of his recommendation are as follows: 

- compare promises to deliverables 

- monitor operational performance through observation 

- evaluate the quality of information 

- evaluate security, backup and recovery provisions 

- determine adequacy of system documentation 

- interview users 

As a result of this, the review should reveal system problems 
and recommendations from the users. Both are vital for 
continuity of system expansion and growth. More detailed 
recommendations for what a post implementation review can 
entail can be found in works by Senn [Ref. 16:pp. 542-547] and 
Lucas [Ref. 18:pp. 515-521]. 

b. Policy and Standards 

(1) Measurement . In following the system model, 
a post implementation review serves to measure the actual 
performance of a system against a standard, or what it was 
intended to accomplish. As a result of this comparison, 
positive action can be taken to correct any discrepancies 
discovered . 

Defining exactly what the SNAP- 1 1 system was 
intended to do may be difficult. From one aspect, one may 
simply state that if it accomplishes the specific functions 
it was programmed to do, then it is a success. However, the 
programming or software function is just one part of a computer 
system. As defined by Kroenke [Ref. 14:p. 22], hardware. 
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software, data, procedures and personnel constitute a computer 
system. Therefore, to measure the effectiveness of the system, 
all must be measured against a standard. 

(2) Standards . As the SNAP-II program has been 
implemented, it appears that only four of the five components 
of a computer system as defined by Kroenke have some standard 
established. Hardware, software, and data are sufficiently 
defined and standardized by project documentation. The pro- 
gram implementation document and Type Commanders instructions 
specify what personnel shall be used and what training they 
will receive. From a system viewpoint, procedures are 
partially unspecified. Certainly, there are procedures 
specified as to how to run and manage the system itself, but 
there is no guidance as to how to integrate the SNAP- II system 
procedurally into the overall current ships organization and 
operation . 

There are two directions from where procedural 
or policy guidance and standards for SNAP-II integration into 
the organization can come from: the ship's administrative 

commander (i.e.. Type Commander) and the shore establishment, 
which has cognizance over Navy-wide management and support 
systems, such as the supply and maintenance systems. 

Frustration was evident in all reviews 
because of a lack of policy guidance as to how to integrate 
the SNAP-II system into the management of the ship. Kroenke 
has categorized computer systems according to how they are 
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employed in the managment of an organization, as cited 
previously. Some ships are utilizing the system as a trans- 
action processing system, while some are a level above and 
attempting to use it as a management information system. Some 
standard or policy must be established so that system use is 
uniform and fleet units can use the SNAP-II system to its full 
potential . 

There is little or no policy guidance as to 
how the SNAP-II system is to be integrated with shore establish- 
ment responsible for supporting the fleet. This has been 
commented on in various ships in relation to the 3-M System 
and the supply organization, and has been evidenced through 
ships still being required to furnish "hard copy" documents 
to shore activities to accomplish maintenance actions, such as 
work requests (OPNAV 4790/2K) and measure calibration. 

Further, several ships report that the shore establishment 
is not prepared to deal with an automated ship, and does not 
fully understand what the SNAP-II system is capable of doing. 

2 . Documentation 

The issue of documentation was raised from two view- 
points; inadequacy of documentation to assist and educate 
the manager, and that existing documentation suffers from a 
lack of readability and organization. The later may well be 
the cause of the former. 

The inadequacy of the existing documentation was cited 
as a specific area of concern throughout the reviews, being 



138 



identified as an aggravating factor in the areas of management 
and training in relation to the SNAP- II system. 

a. Management Perception 

The underlying reasons for the dissatisfaction 
with the current documentation are varied in nature. Generally, 
the data-entry personnel are not reported as having problems 
with documentation, only the personnel concerned with management. 
Specific attributes of the documentation and circumstances were 
not cited , just a general lack of confidence and use brought 
on by negative initial impressions. 

In this sense, the documentation provided was 
viewed as adequate for guiding personnel in the entry of 
specific data in specific menu-driven screens, but of limited 
use in answering questions or as a management tool. 

The managers expressed concern that the documen- 
tation was hard to use and difficult to understand. They felt 
it was written for "computer literate" people, finding the 
terminology confusing and lacking a management summary. They 
could not easily reference the document for questions of a 
broad nature and the documentation did not illustrate the 
inter-relationships between subsystems and data. 

b. Management Needs 

From a management perspective, the guides and 
manuals provided are inadequate. This has been brought up 
repeatedly in the case studies and cited as a primary reason 
as to why middle level managers and Command level personnel 
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have not utilized or integrated the SNAP-II system to its 
full potential. There is no documentation available that gives 
information a manager can use effectively; it appears that all 
documentation is geared either to the data entry user or as a 
reference document for hardware and/or software maintenance. 

Managers, as a group, have specific tasks and needs 
in relation to an information system that should be identifiable. 
Cohen and Cunningham discuss the creation of effective manuals 
for specific readers to perform specific tasks [Ref. 19:p. I]. 
Expanding on this, they maintain that different users need 
different information, with many ways to classify manuals-- 
according to type of job, location, and intended audience 
[Ref. 19:p. X]. The existent SNAP-II documentation does not 
single out specific groups of users or provide guidance and 
reference tailored to specific needs. While the information 
is all there, it is essentially "buried" and managers are 
loathe to dig through the documentation to extract what they 
can use. 

If the system is to succeed, management must 
understand it and be able to use it. Perryman notes that the 
quality of documentation is a major determinant of how well a 
system is received and how widely it is used [Ref. 20:p. 35]. 
McCann [Ref. 21:p. 8] also places emphasis on the quality of 
system user documentation in improving the benefit derived 
from a computer system. 
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c. Training 

The adaptability of documentation to the training 
environment was brought up as an issue. In the present format, 
it was not viewed as a training document because it is oriented 
mostly as a reference, and was not suitably arranged by topic 
area. An idea advanced by Cohen and Cunningham is the concept 
of "bridging" the old system to the new one [Ref. 19:p. 137]. 
Under this concept, the user of the documentation should be 
given an explanation and example of the "old" and "new" at the 
same time. Applying this to the SNAP-II system, there is very 
little graphic display of what the "old" manual forms looked 
like and where information was entered on it, and how this 
relates to the SNAP-II system. It would be of great value in 
training new users who are presumed to have knowledge of manual 
system procedures. 

d. Source of Documentation 

The directives that NAVMASSO has promulgated con- 
cerning the development of end-user documentation [Ref. 22], 
and [Ref. 23] comply with the standards established by the 
Secretary of the Navy [Ref. 24;Encl. (1)]. On examination, 
these standards specify only the format of the documentation, 
and does not address itself specifically as to v\^hom the 
documentation is aimed, stylistic content or provide guidance 
as to what constitutes "good" user documentation. 

As these standards were developed prior to or 
during 1979 (pre-SNAP era), they may have been intended 



141 



specifically for use by data-processing professionals who have 
initial understanding about computer systems. Since that time, 
the advent of computer systems (such as SNAP- 1 1) where novice 
end-users are placed in an interactive status requires a whole 
new approach to documentation- - the target audience is a 
completely different one. 

e. Existing Documentation 

There are four types of documentation available 
to the fleet user for SNAP-II: 

- SNAP-II Management Guide 

- On-line Users Manual 

- Users Guide 

- Desk Top Guide 

With the exception of the management guide, there are separate 
manuals and guides for each subsystem of the SNAP-II system. 

The management guide gives a brief introduction 
to the SNAP-II system, history of software releases, and a 
brief, general description of each subsystem without reference 
to specific input or output. It could be confusing to a new 
manager/user, as it is interspersed with computer terms and 
does not state exactly what the system can do for a manager. 

It is geared toward managing the SNAP-II system, not managing 
with the SNAP-II system. 

The on-line users manual is essentially a printed 
version of the system's on-line "AID" feature, with the 
objective of providing information to the user so he can use 
the particular subsystem effectively. Little use is made of 
graphics (except for type written screen examples) , with text 
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filling the entire page. The content is organized using 
engineering notation (e.g., 3.1.5.2.1.16), without breaks 
between subjects, or tabs provided for easy subject or 
category reference. The approach to explaining the use of 
the subsystem is "top down”, i.e., it starts at the entry 
point to the subsystem and goes down through each module, sub- 
module, etc., with screen numbers used as reference, explaining 
how to input data to each individual data entry screen. Table 
V is a typical example [Ref. 19]. A review of one manual, 
the Maintenance Data Subsystem on-line users manual [Ref. 24] 
showed a text of 862 pages, with the table of contents 
(example in Table VI) alone running 27 pages. The documentation 
is very complete--it tells a user everything that is applicable 
to a subsystem. Herein lies the paradox--it overwhelms the 
reader by being too complete and hides information by virtue 
of poor format. 

The users guide is a reference document intended 
for users having knowledge of the system in the first place. 

It lists and cross references files and programs, gives data 
element configurations, and lists error messages and corrective 
actions. Of all the documentation, this is the only one that 
lists the reports available from a subsystem in one place. 

The desk top guide is a self-study document for 
new users. It is set up for a user to learn and master 
specific functions, but does not give a system overview. 
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TABLE V 



EXAMPLE OF PAGE OF ON-LINE USERS MANUAL 



3. 2. 2. 2. 2. 2 Online Tickler Report by Item ID (MDS490) . This screen presents 
sunmary or recoros that taiT within the range or t liter values specified. 
The suinmary includes item ID, management code, description, work center and 
due date. This screen allows you to display a selected record (determined by 
cursor position) on a data display screen. PFKey options available from this 
screen are described below. 



REFERENCE 

PARAQUPH 

PFl - Review Record 3.2. 2. 2. 2. 3 

(This option presents a data display screen 
prefilled with data from the cursor -specified 
record. ) 

PF9 - First Page 

(Depressing this option causes the first page of 
the report to be displayed. If the report does 
not have multiple pages, this option will not be 
available. ) 

PF12 - Next Page 

(Depressing this option causes the next page of 
the report to be displayed. If no aoditional 
pages remain, this option will not be available. ) 

Additional PFKeys available are PF13 for general aid as described in 
paragraph 3.1.3, and PFKeys 14, 15, and 16 as described in paragraph 2.1.4.4c. 

3.2. 2. 2.2.3 Review Record for Report by Item ID (MDS5Q8) . This screen 

presents a data display of the record selected from the Online Tickler Report 
by Item summary screen. Fields will be prefilled with existing data and 
nonmodifiaole. Selection of EUTER will return to the suirroary screen. 
Additional PFKeys available are PF13 for general aid as described in paragraph 
3.1.3, and PFKeys 14, 15, and 16 as described in paragraph 2.1.4.4c. 

3. 2. 2. 2. 2. 4 Select Options for Report by Date Due (MDS492) . This filter 

screen enaoles you to select a specific range of records for the on-line 
report by oate due. Values that may be entered are beginning and ending Item 
ID*s, beginning and ending IXie Dates, a Modified Since Date, specific 
Management Codes and/or 'work centers (you must change the fields to *Y*). The 
first work center field will be prefilled with your primary work center. If 
you have multiple work center access, this field will be modifiable. Fields 
may be left blank. If fields are left blank, all values for those fields will 
be eligible for selection. Date value, if entered, must be in DD MMM YY 
format. Selection of ENTER initiates validation of the filter values 
entered. If any field is in error, the filter screen is redisplayed with 
invalid fields blinking. When no errors exist, record selection begins. 
Records meeting the range of filter values are displayed on the Online Tickler 

Report by Dace Due summary screen (refer to paragraph 3. 2. 2. 2. 2. 5) . If no 

records qualify, the filter screen is redisplayed with the message, “NO 
gUALIFYING TICKLER RECORDS FOUND". Additional PFKeys available are PF13 for 
general aid as described in paragraph 3.1.3, and PFKeys 15 and 16 as described 
in paragraph 2.1.4.4c. 
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TABLE VI 



EXAMPLE OF PAGE FROM TABLE OF CONTENTS 



TABLE OF aOCTTENTS (cont.) 

3. 2. 2. 2. 3. 2 Select Cations for Tickler 369 

Modification (MDS482) 

3. 2. 2. 2.3. 3 Summary of Items for Modification 372 

(I>1DS484) 

3. 2. 2. 2.3. 4 Modify Tickler File Record (MDS486) 372 

3. 2.2. 2. 3. 5 Review Tickler Record for Modification 375 

(MDS657) 

3. 2. 2.2. 3. 6 Delete Tickler Record Verification 375 

(MDS514) 

3. 2. 2. 3 Add New Ship's ^ckler File (MDS465) 375 

3. 2. 2. 4 Delete Tickler File Selection (MDS467) 379 

3.2. 2. 4.1 Delete Tickler File Verification 379 

(MDS477) 

3. 2. 2. 5 Order Nonmaintenance Related Supplies 379 

3.2.3 Equipment Configuration and Logistics 382 

Support (MDS442) 

3.2. 3.1 On-line Equipment Configuration Reports 385 

Menu (MDS819) 

3. 2. 3. 1.1 On-line- Report Equipment System 387 

Identification (MDS821) 

3. 2. 3. 1.1.1 On-line Report Eiquipment System Ident 389 

by SWLIN (MDS831) 

3.2. 3. 1.1. 2 On-line Report Equipment System 391 

Identification by APL (MDS823) 

3.2.3. 1.2 On-line Report APL Summary List 393 

(MDS825) 

3. 2. 3. 1.3 On-line Report Restrict Equipment File 395 

Search Options (MDS861) 

3. 2. 3. 1.3.1 Equipment File Search Warning 395 

(MDS835) 

3. 2. 3. 1.4 Find Eqpt by Logistics Support Data for 398 

Eqpt Update (MDS908) 

3. 2. 3. 1.5 On-line Report Equipment Summary List 400 

(MDS827) 

3. 2. 3. 1.6 On-line Report APL Characteristics Data 400 

(MDS860) 

3. 2. 3. 1.7 On-line Report Detailed Equipment Data 404 

(MDS829) 

3. 2. 3.1. 8 Additional Equipment Data (MDS849) 404 

3. 2. 3. 1.9 General Logistics SUf^rt Data SUirsnary 407 

(MDS912) ' 

3. 2. 3. 1.9.1 Equipment XREF For Logistics Data Item 407 

(l>n)S910) 

3. 2. 3. 1.9.2 General Logistics Support Data Detail 411 

(MDS911) 

3.2.3.1.10 Equip Dependent Logistics Data Summary 411 

(MDS931) 
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£. Documentation Design 

It would appear that the designers of the system 
have taken considerable effort to ensure "user friendliness" 
through the design of system architecture and user- interface , 
but have neglected documentation. Hulme [Ref. 26:p. 57] 
states : 

The ease of understanding a piece of written material will 
depend not only in the characteristics of the passage, e.g., 
how clearly it is printed, its grammatical form, etc., but 
also upon the readers past experience and familiarity with 
the concepts involved. 

Various authors have stressed the importance of 
using plain English without technical jargon in system 
documentation [Ref. 19:p. 6] and [Ref. 20:pp. 36-37]. The 
existing SNAP-II documentation is replete with "computerese"; 
"cursor selected", "screen fields", "selected data type", 

"card image format" and similar terms appear all too often, 
and serve to confuse the reader. Excessive internal cross 
referencing is also a detracting factor. 

Format and organization of text can be extremely 
important. For example, in one passage from the MDS on-line 
users manual, the explanation for one screen is a solid block 
of text running half the page, single spaced. Perryman 
recommends that text be uncluttered, neat with wide margins, 
and that it be complimented with effective charts and diagrams 
[Ref. 20:p. 58]. The physical separation of chapters (e.g. 
visual cue) is also recommended, which is lacking in SNAP-II 
documentation . 



146 



3 . Training 



a. Strategy 

In the overall training strategy of the SNAP-II 
system, NAVMASSO is tasked with providing the initial 
implementation training for the end users on board ship. The 
formal training relationship with NAVMASSO is complete upon 
implementation, and by extension, NAVMASSO will be out of the 
training business when all ships have had SNAP-II implemented. 
Concurrent with the phase-out of NAVMASSO in the formal 
training arena is the emergence of formal training responsi- 
bilities within the Navy training establishment. 

As of January 1986, the Navy training establishment 
has not commenced a full scale training effort for the SNAP-II 
program. Various training commands and schools have included 
some SNAP-II training to one degree or. another, but not all 
have integrated SNAP-II either specifically or as a subset to 
current instruction or subject areas. In and of itself, -even 
though formal training has lagged implementation by several 
years, this overall strategy is not seen as having had a 
deleterious effect on the success of the SNAP-II program, due 
to the effort by NAVMASSO to assist informally after imple- 
mentation and because of the relative lack of sophisticated 
employment of the system by fleet users at this point in the 
life of the SNAP-II system. This has, however, limited the 
ability of some ships to fully utilize the SNAP-II system and 
derive its intended benefits. This strategy and current status 



147 



of training should, however, be communicated formally to fleet 
users so that they will not become complacent and allow the 
system to stagnate or digress. 

b. Thrust of Training 

The emphasis of the training for the SNAP-II system 
should focus on the type of training and long term objectives, 
with "Who" is conducting the training as a minor issue. The 
concept of training in relation to a computer system can assume 
diverse perspectives. Differentiation can be made between 
users and managers [Ref. 27:p. 30], initial versus recurring 
training [Ref. 14:p. 63], system versus application (or 
product) training [Ref. 16:p. 528], and concept development 
versus specific skill training [Ref. 27:p. 32]. All of the 
aforementioned must be considered when designing and imple- 
menting a training program for a computer system. The success 
or failure of the system, or its effectiveness and efficiency, 
can be driven by the training afforded the end us-er [Ref. 14: 
p. 64]. In its current state, managers as a group are not 
being trained. 

(1) User vs. Manager Training . Under the current 
implementation strategy, NAVMASSO is tasked with providing 
the initial end-user training in order to place the SNAP-II 
system in an operational status. There is no sub-strategy as 
to what kind of end user is being dealt with. As in the 
documentation issue, training should be tailored to the 
function of the end user in question. The Commanding Officer 
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or a Department Head will have different views of the system 
than a data entry user, and should be trained with their 
different perspectives in mind. The relationship of training 
to documentation, however, should not be regarded such that 
one is a substitute for the other. Senn warns that good 
documentation should not be a substitute for training [Ref. 

16:p. 528]. 

(2) Recurrent Training . Once implementation 
training has been accomplished, the end user should not be 
left on his own nor should training be regarded as complete. 

Both Eibes and Kroenke address the idea of recurrent training. 
Eibes [Ref. 27:pp. 30-33] recommends a three stage "curriculum" 
approach to training end users. In the first stage, the "How 
to" aspects are addressed to novice users, focussing on the 
mechanics of utilizing the hardware and an introduction to the 
software. The recurrent training philosphy is embodied in 
stages two and three. Stage tv^^o entails the idea of educating 
users (and managers) instead of training, with the focus on 
concept development versus skill training. Stage three, which 
may be beyond the scope of SNAP- II, deals with concerns about 
data integrity, documentation of software developed by users, 
and system accountability, security and controls. Implementation, 
or stage one training, is not completely ignored after imple- 
mentation, as there will always be new users. 

Applied to SNAP-II, initial training has been 
provided for, but recurrent training has not. This type of 
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training can be divided into two areas- -that which should be 
conducted on board, and that which should be conducted at 
fleet training centers or schools enroute to sea duty. 

Training syllabi and materials for afloat 
recurrent training should be developed and provided to ships 
when the system is implemented. In a paper on user interface 
design [Ref. 27:p. 171], Thimbleby recommends that such 
material be provided by the designer of the system, which in 
this case can be construed as being either the functional 
manager or NAVMASSO. Currently, the subject of recurrent 
training is handled in diverse ways. Some ships have a strong 
training program, but it is a re-run of the implementation 
training. Guidance is necessary so that ships can carry on a 
strong continuing, or recurrent training program to develop a 
system-wide perspective of SNAP-II versus a narrow and specific 
subsystem application view. 

Training conducted by shore commands will not 
be addressed here as there is insufficient experience and data 
to make any objective evaluations. 

(3) The "Selling of the Product" . The lack of a 
systems perspective by the end-user managers may be a 
detracting factor in the successful implementation and use of 
a computer system. The manager must understand how the system 
affects him and his personnel. This form of training, or 
education, is not present in the training strategy of SNAP-II. 
Eibes [Ref. 27:p. 22], in addition to the various attributes 
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of stage two of his three-stage curriculum, states that the 



"marketing” or "selling" of an information system to managers 
occurs at this point: 



However, a majority 
will originate from 
executive positions 
called 'education’, 
'selling' being pre 



of those receiving systems education 
the supervisory, managerial or even 
. . . The process may not even be 

with terms such as 'marketing' or 
f erred . 
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VII. CONCLUSIONS AND RECOMMENDATIONS 



Given the diversity and magnitude of the SNAP- 1 1 program, 
a considerable degree of success has been achieved in 
implementing an interactive computer system in independent 
afloat units having novice users, operators and maintainors. 

The system has been received in a positive manner by all ships 
that were a part of this review. A adjectival summary of 
various aspects of the SNAP- II program from the end users 
perspective is included as Table VII. 

The end users have been generally satisfied with the 
implementation process. While there have been problems with 
constructing the initial data bases, these are not seen as 
major obstacles. The performance of NAVMASSO and the NAVSEACEN’s 
in their implementation and support roles have been consistently 
very good. 

The hardware and software elements of the SNAP- 1 1 program 
have been well received by the ships reviewed. The subject 
of the adequacy of the numbers of terminals was raised 
repeatedly, suggesting that this area needs further consider- 
ation. As an adjunct to this, several ships have reported that 
the word processing function seriously slows down system 
response time, although this was not quantifiable. An 
alternative to this, should it be technically and economically 
feasible, would be to install "intelligent terminals" capable 
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SUMMARY OF SHIPS EVALUATIONS 
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of handling the word processing function locally instead of 
in the Central Processing Unit. These terminals should remain 
networked to the minicomputer for the purposes of performing 
the designed SNAP- 1 1 functions. 

The degree of integration of the SN.'\P-II system into the 
shipboard operating environment has varied from ship to ship. 

As has been noted, some ships are operating different types 
of computer systems -- some at the basic transaction processing 
level, some at a higher level. The level of computer expertise 
and character of the command prior to SNAP- 1 1 implementation 
has had a certain bearing on this, but there are also external 
intangible, or non-material factors that are influencing this. 

As noted, documentation for end users was not considered 
effective by the ships interviewed. Closely related to this 
was the type of training being conducted for shipboard 
personnel. Both these areas require revision to increase the 
effectiveness of the SNAP-II system and insure that all levels 
of end users are utilizing the system to its full extent. 

A difficult area to assess is the SNAP-II program itself. 

End users have voiced concern about what they perceive as a 
lack of policy guidance and an understanding of just how 
SNAP-II is to be used in relation to managing their ships. In 
and of itself, this may reflect a lack of adequate communication 
between the fleet and program management. 

The program has provided for four of the five components 
of a computer system as defined by Kroenke, leaving the key 
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area of ''procedures'' in an undefined state. This is not a 
fault of the program. An analogy that best illustrates this 
drawback would be the procurement of a weapon system. A 
program manager would be responsible for obtaining the hardware 
itself, but would not be responsible for developing tactics to 
employ it. This is where SNAP-II finds itself. 

Because of the different functional managers and sponsors 
present in the SNAP-II program, there are diverse forces at 
work. Each is interested in ensuring that their subsystems 
are functional and implemented. While the SNAP-II program 
office is concerned primarily with implementing the system 
in the fleet (which it is doing well) , it appears no one office 
is charged with absolute control as to what exactly the SNAP- 
II system is to be or how it is to be integrated into the 
management of a ship. Ostensibly, the Program Coordinator 
(OP-945) should be in full charge of these matters, but that 
may be impracticable given the nature of the organization- - 
they are concerned with computer systems, not management of a 
ship. The identification of a central point charged with 
defining exactly what SNAP-II is to do and how it is to do it 
is highly recommended. Once this is accomplished, standards 
can be developed and promulgated to fleet units. 

Having implemented the SNAP-II system, some gauge of its 
effectiveness and use by fleet users is necessary, both to 
point out areas for possible improvement in the program and 
to ascertain that fleet units are using the system to its 
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full benefit. A post implementation review process as an 
integral part of the SNAP- II implementation process is highly 
recommended. Standards must be developed to accomplish this, 
as noted in the preceding paragraphs. 

In summary, the Navy has introduced a computer system that 
has been well received by the fleet users interviewed. However, 
there are concerns and minor problems that prevent it from 
being utilized to the most efficient extent possible. These 
can be corrected by: 

. better communication with the end user 
. revision of training policy 
. revision of documentation 

. identification of a central control point for program 
policy, guidance, and standards 
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APPENDIX A: ACRONYMS 



3-M - Material Maintenance Management Program 

ADM - Admnistrative Data Management Subsystem 

ADP - Automated Data Processing 

AE - Auxiliary - Ammunition ship 

APS - Auxiliary - Refrigerated Stores ship 

AIS - Automated Information System 

AMS - Aviation Maintenance Subsystem 

AO - Auxiliary - Oiler 

AOE - Auxiliary - Ammunition/Oiler 

AOR - Auxiliary - Oiler/Replenishment 

APL - Allowance Parts List 

ASW - Anti-submarine Warfare 

BB - Battleship 

BOR - Budget OPTAR Report 

CASREP - Casualty Report 

CDA - Central Design Activity 

CG - Guided Missile 

CGN - Guided Missile Cruiser Nuclear Powered 
CIC - Combat Information Center 
CK - Configuration Change 

CMPM - Current (Ship's) Maintenance Project Master 
CNO - Chief of Naval Operations 
CO - Commanding Officer 
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COBOL - Common Business Oriented Language 
COM - Communications 

COMNAVSURFLANT - Commander, Naval Surface Forces, U.S. 

Atlantic Fleet 

COMNAVSURFPAC - Commander, Naval Surface Forces, U.S. 

Pacific Fleet 

COMSUBPAC - Commander Submarine Force, U.S. Pacific Fleet 

CONUS - Continental United States 

COSAL - Consolidated Shipboard Allowance List 

CPU - Central Processing Unit 

CSO - Combat Systems Officer 

CSMP - Current Ship's Maintenance Project 

DD - Destroyer 

DDG - Guided Missile Destroyer 
DH - Department Head 
DLR - Depot Level Repairable 
DS - Data System Technician 

DSC - Data System Technician Chief Petty Officer 
DSS - Decision Support System 
EM - Electrician Mate 

EMC - Electrician Mate Chief Petty Officer 

EMO - Electronics Material Officer 

ET - Electronics Technician 

EW - Electronic Warfare Specialist 

FAS - Functional Area Supervisor 

FF - Frigate 

FFG - Guided Missile Frigate 
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FTC - Fleet Training Center 
FY - Fiscal Year 

INSURV - Board of Inspection and Survey 

LOGMARS - Logistics Application of Automated Marking and 
Reading Symbols 

LPD - Landing Platform Dock 

LST - Landing Ship Tank 

MDS - Maintenance Data Subsystem 

MEASURE - Metrology Automated System for Uniform Recall and 
Reporting 

MIS - Management Information System 

MLS - Mobile Logistics Support Force Subsystem 

MMCM - Machinist Mate Master Chief Petty Officer 

NAMMSO - Navy Material Management Support Office 

NAVMASSO - Navy Management Systems Support Office 

NAVMASSO DETPAC - Navy Management Systems Support Office 

Detachment Pacific 

NAVSEA - Naval Sea Systems Command 

NAVSEACENLANT - Naval Sea Systems Command Center Atlantic 

NAVSEACENPAC - Naval Sea Systems Command Center Pacific 

NAVSUP - Naval Supply Systems Command 

NEC - Navy Enlisted Classification 

NMPC - Navy Military Personnel Command 

NSCS - Navy Supply Corps School 

NWS - Naval Weapons Station 

OMMS - Organizational Maintenance Management Subsystem 
OPNAV - Office of the Chief of Naval Operations 
OPS - Operations Officer 
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OPTAR - Operating Target 
PC - Postal Clerk 

PCO - Prospective Commanding Officer 

PCS - Permanent Change of Station 

PMS - Planned Maintenance System 

PNl - Personnelman First Class 

PNC - Personnelman Chief Petty Officer 

PQS - Personnel Qualification Standard 

RAV - Restricted Availability 

RFT - Ready For Training 

SDSA - Source Data System Afloat 

SECNAV - Secretary of the Navy 

SEF - Ship's Equipment File 

SEE - Selected Equipment List 

SFM - Supply and Financial Management Subsystem 

SFOEDL - Summary Filled Order and Expenditure Difference 
Listing 

SFOMS - Ship's Force Overhaul Management System 
SFWL - Ship's Force Work List 
SK - Storekeeper 

SKC - Storekeeper Chief Petty Officer 

SKC’S - Storekeeper Senior Chief Petty Officer 

SMA - Systems Management American Corporation 

SMS - Systems Management Subsystem 

SNAP - Shipboard Non-tactical ADP Program 

SOAP Team - Supply Overhaul Assistance Program Team 
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spec - Ship's Parts Control Center 
SWO - Surface Warfare Officer 
SWOS - Surface Warfare Officer School 
SWOSCOL - Surface Warfare Officer School 
TAD - Temporary Additional Duty 
TECDOC - Technical Document Module 
TYCOM - Type Commander 

UADPS - Uniform Automated Data Processing System 

UNREP - Underway Replenishment 

VOS - Vulcan Operating System 

WSF - Weapons Systems File 

XO - Excutive Officer 

YNC - Yeoman Chief Petty Officer 
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